Project-system: Fix File Rename

[tmeschter]

When the user renames a file in Solution Explorer, we should offer to rename the class inside the file as well. However, there are a number of related issues with the current implementation. This issue tracks making the feature work as expected.

Child items:

• [ ] #228 - Rename of file should listen to Language service Notification rather than workspace changes
• [ ] #407 - Rename prompt appears after the project has been unloaded
• [ ] #803 - File rename fails the first time
• [ ] #958 - Renaming a file only by case results in a error
• [ ] #1020 - Rename prompt should respect UI suppression for automation at the time when the operation was invoked
• [ ] #2704 - Rename Fails when class is already named the target file name
• [ ] #3103 - Rename .cs -> Refactor prompt slow for .NET Core/Standard projects, but fast for .NET framework projects
• [ ] #4537 - Renaming a file doesn't prompt to rename the type
• [ ] #4538 - Rename file from solution explorer might loose changes and undo doesn't work

The most fundamental problem is that the rename event we listen to from CPS is in no way correlated to when the rename is pushed to the Roslyn workspace. As a result, we might not ask the user to rename the class at all, or the dialog might pop up much, much later--even after the project has closed. We need to fix that problem first.

The evaluation subscription normally tells you when files have been renamed, and this would provide us a solution to the problem. However, there is currently a bug that causes the rename to instead show up as a paired add and remove. This is being tracked by bug https://devdiv.visualstudio.com/DevDiv/_workitems/edit/499709 and we will not be able to make progress until it is fixed.

[Liversage]

Related (actually, the reverse): Renaming a class in the VS editor should also rename the containing file

[SamirBanjanovic]

What's the update on these issues? Doesn't seem to have been an update in a while.

[jmarolf]

I do not consider rename fixed. I am planning to have the re-architecture done for 16.3

[SamirBanjanovic]

great! Oddly, it's probably the only issue keeping our team from adopting VS2019.

[StingyJack]

@jmarolf - Why is this issue closed when the expected behavior still does not exist in VS 2019?

Renaming a file and being prompted to to rename the type has worked just fine in VS for a long time, Why didnt anyone notice it became broken?

[jmarolf]

I recently checked in the fixes for this. this fix will be released in 16.3

[StingyJack]

I saw that and appreciate the fix.

If you could pass along to whomever the PM's are for this that I dont appreciate all the mismatched file/class names I have to deal with for another few months until the correction materializes where I can utilize it. I also dont appreciate what seems to be an absence of any kind of QA or continuity in MSFT output. If y'all are hell bent on forcing .netcore, sdk style projects, and package reference on us, with all the warts and growing pains (repeated bugs and mistakes) that come with rewrites (that could have been avoided), then there needs to be continuity in usage and parity in feature/function.

It isn't about "moving the cheese", this is more like replacing the cheese we have been buying with milk and a defective coagulant - it requires the consumer to expend more effort and they still wont get the result they were expecting.

[fredrikhr]

@StingyJack just out of curiosity, in a product that uses two component versioning, how do you figure a new release can happen quicker than incrementing the minor version component?

@jmarolf I guess the fix will end up in VS Preview faster than in stable release, so I'll encounter the fix pretty soon if I update my preview track?

[StingyJack]

@couven92 - id expect it in the next patch release, not two minor versions from now. They are using a three part version (mostly).

[SamirBanjanovic]

What under the hood changes were made to break this feature? This has been around as long as I can remember, and never has a version change broken it? If QA was involved it should have been caught. If test driven dev was involved it should have been caught. If any kind of other testing was involved it should have been caught. I appreciate all the work put into this product, but I am having a hard time seeing how such a feature broken for a major release.

[Liversage]

@SamirBanjanovic As far as I know this is only a problem with .NET Core projects or the new project system if you will. So from an internal standpoint this is not broken. It's just a feature that is missing. Obviously, users (you and I) may perceive it differently.

[SamirBanjanovic]

@Liversage this feature works correctly for me in vs2017 for both classic and core project

[StingyJack]

So from an internal standpoint this is not broken

If anyone at MSFT has this viewpoint they need to be tarred and feathered, or be forced to work with the consequences of viewpoints like this.

MSFT is a tool vendor. They can't replace a claw hammer with a peening hammer when the expectation includes removing nails, and it doesn't matter a bit how great the peening hammer can bend metal.

[HoffmannChris]

This of course is broken for me as well, using VS 2019 Enterprise 16.2.1. This is feature that I rely upon quite heavily. @jmarolf , is there a known release date for 16.3?

[drewnoakes]

@HoffmannChris 16.3 preview 1 is available now.

https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes-preview

There's no date for the 16.3 GA yet, but there will likely be more previews before then. You can run VS versions side-by-side so there's no downside to installing the preview other than the disk usage.

[S0und]

Is this ever gonna be fixed? I mean, i'm on 16.7.2 and it's still broken.

https://giant.gfycat.com/LinearHopefulAlabamamapturtle.webm

[Liversage]

Is this ever gonna be fixed? I mean, i'm on 16.7.2 and it's still broken.

I don't think that the feature you describe as broken is in scope of this issue. You rename Form1 - Copy.cs to Form2.cs but this file contains the source code for the class Form1, not the source code for a class named Form1 - Copy (obviously not a valid class name in C#).

I believe the feature tracked in this issue is when you rename a file containing a type with the same name as the file (e.g. Form1 in Form1.cs). Then you are asked if you also want to rename the type to match the name of the file and this feature absolutely works in Visual Studio.

The file that you are renaming does not match the name of the type in the file. However, you could instead try to rename Form1.cs to Form2.cs. Then the feature would kick in but both Form1 classes (the original and the duplicate) will be renamed to Form2 so you still have to fix your code by editing the duplicated file.

[davkean]

@S0und Please open a new issue to track that feature, it's a good issue that we should look into addressing.

[davkean]

@ryzngard ^ we should make https://giant.gfycat.com/LinearHopefulAlabamamapturtle.webm work.

[drewnoakes]

Arguably it's the paste operation that got things into bad shape here, not the rename. Perhaps pasting a source item should produce type Form1Copy, so that the code never ends up in an invalid state.

[ryzngard]

I agree, but I don't think it hurts to have a discussion about rename where there's only one type declaration. If that type doesn't match the file name, should we rename anyways?

What if it doesn't compile, should it just be a syntactic rename (basically find and replace in the file and update the constructor name). That wouldn't work for EVERY case, but more or less would be right

[ryzngard]

Another similar request came in for feedback, tracking with https://github.com/dotnet/roslyn/issues/49211