Roslyn: Move Code Experience

[mikadumont]

Move File/Folder

• [x] 1. When moving or renaming a file/folder the namespaces should be renamed automatically.

Tracking https://github.com/dotnet/roslyn/issues/48443
Tracking issue on project system: 6658

• [ ] 2. Adjust namespaces refactoring - Apply the change namespace refactoring to each file/folder/project selected in Solution Explorer; the new namespace should be the default namespace for a new class defined in the given folder/project.

Tracking https://github.com/dotnet/roslyn/issues/33877 and https://github.com/dotnet/roslyn/issues/46486

• [ ] 3. Have the option to undo moving a file/folder - Have the following warning dialogue pop up.
  

Tracking https://github.com/dotnet/roslyn/issues/48444
Tracking issue on project system: 6089

Move Type to File

• [ ] 1. Have an option to move a type to another file even if there is only one type in that file:

Dialogue to look similar to Move to namespace and have an option to remove source file:

Once you select Ok the namespace and type will then get moved to the destination file and if the remove source file is checked the source file will get deleted.

Tracking https://github.com/dotnet/roslyn/issues/48445

Move Method

• [ ] 1. Create an option to move a method to another file or namespace.

Rename a Project should rename Namespace and Class

[ryzngard]

Create an option to move a method to another file or namespace

Methods cannot be top level in namespaces, we should be careful about wording here.

One thing this issue seems to be lacking is providing more overarching guidelines for how we get context. This may be partially covered by the work from @petrroll with the added standardized helpers. Have consistency in how selection should work would be good.

Also, what are the thoughts on adding a shortcut for a general move command/dialog? Context aware based on selection, combines all of these actions.

[ryzngard]

Current Planning

Moving Files

We're working with project team to standardize moving files and symbol rename. This will happen in a few phases:

1. Working on public API tell Roslyn to handle the symbol renaming from the project side
2. Adding a rename API to reduce loss of information from remove/add that's currently needed today
3. Update project system to use new APIs with current user experience
4. Once proven out, we can adjust the user experience to a better design.

Once all of that is complete, we will move to a design where symbol renaming happens automatically. Details tbd on the heuristics we use to determine when to perform that operation, and if/how users can enable or disable this feature.

This work solves the immediate customer ask for enhanced behavior when moving files. It should be seamless that a rename or file move maintain the correct symbol or namespace name. The above design also has the benefit of allowing us to easily incorporate these changes into the undo stack.

Moving Symbols

This is categorized as moving named types such as interfaces, enums, classes, methods, properties, etc. The idea here is that we can enrich and share UI across experiences. We don't have a concrete design for this, but it will be the next step after "moving files" work is done. The need is clear, and these are the scenarios we're targeting:

Rename Project Experience

I would consider this lower priority. We should evaluate user need and desired experience before moving forward on this. Consider longer term, and do above features first.

[petrroll]

IIRC: Since most moveXZY refactorings work on multiple elements at a time / have more complicated selection of types of nodes they work on I think they haven't been moved over to current helpers / can't be brought over without at least moderate investment.

[CyrusNajmabadi]

Once all of that is complete, we will move to a design where symbol renaming happens automatically. Details tbd on the heuristics we use to determine when to perform that operation, and if/how users can enable or disable this feature.

Please be very careful about this. I've used tools that do auto-renames and it can be an awful experience. It's especially bad when you're in the middle of things, haven't comitted to git in a while, and then get a rename that for some reason can't be undone (which is not uncommon). Now you're literally screwed.

I often accidentally grab/move files when trying to double click on them. i.e. i click while still moving the mouse. so it registers as a grab and can totally end up moving into another file. Having this now be enormously heavy weight, and not something i can eaisly undo is bad.

--

IMO, you should take a note from vscode here (tbh, why aren't teams designing this in concert?). in vscode when you do this sort of thing it asks you questions like so:

This is the right way to do it IMO. Users that like the more invasive operations and higher costs can opt-in. Users that do not like it can opt out. And it's trivial to make a choice here and either make it hte default or punt down the line.

[mikadumont]

Related customer request copying here:

It would be nice to have the option in the Solution Explorer to open the context menu following selection of a defined class within a .cs file and be able to directly access the "Move type to .cs" from within this context menu vs how you can do it today (righ click class in the .cs file, followed by selecting Quick actions and Refactoring, followed by selecting the Move type to option.

I you have multiple classes defined within one .cs file, you would be able to quickly port those classes into their own .cs file without having to browse the file itself or perform extra steps to achieve this outcome. It would be a simple right click of each class you want ported out to its own file and selecting the "Move to type .cs".

[mikadumont]

Related customer request copying here:

When detecting mismatched namespaces have the ability to adjust the namespace on a solution level.

[mikadumont]

Related customer feedback copying here:

When performing a replace all, which could make changes in many pages. You may need to go to every page and resolve the class namespaces. After a (re)build, the error list shows all the missing usings.

If visual studio can detect what the resolve is for 1 item when pressing CTRL+. in one .cs page, then visual studio could also find all related errors with the same code or description and ask to resolve all items the same way.

[CoolDadTx]

I agree with earlier post, this needs to be opt in, not required. There are many reasons to move a file/folder AND NOT have the namespace automatically changed. This should be an option when the move occurs (like the symbolic rename when you rename a file). Sometimes I want the namespace changed, many times I don't. Examples.

• Published libraries that have namespaces already being used and you're moving files for better organization, preparation for a new implementation, moving things into legacy, etc - published namespaces cannot be changed.
• Moving files into "pseudo" folders to avoid the clutter of having them in a single folder. Examples include commonly shared files, files that represent code that needs to be moved to a separate library (_Core), and folders that aren't actually part of the namespace (App_Start)

[tamlin-mike]

-1 for

When moving or renaming a file/folder the namespaces should be renamed automatically.

+1 for

this needs to be opt in

[ryzngard]

@tamlin-mike thanks for the input. I believe the current plan is an option that is a dialog with yes/no or multiple checkboxes (depending on how far the design goes). So it will be optional to perform, but defaults to yes.

The Roslyn public API design was checked in with #41267 which helps show some of the expectations on what will change and what can change. The idea is that the returned actions can be presented to users and performed or not.