Refactoring: Move Static Members to Another Type

[Soreloser2]

Brief description:

Combines #33928 and #22053, allowing for users to move a static member to an already existing type or to create a new static type. Currently we will focus only on movement within the same namespace and project as the original location of the member (to simplify refactoring constraints).

Languages applicable:

Both for C# and VB

Reports on

Any static member of a class, when the cursor is selected on the declaration line, as indicated by the angled brackets <>:

C#:

public class ExampleClass
{
    <public static int DoSomething()>
    {
        return 0;
    }
}

VB:

Public Class ExampleClass
    <Public Shared Function DoSomething() As Integer>
        Return 0
    End Function
End Class

Any static member selected this way will offer a refactoring in the lightbulb dropdown (Ctrl + .) titled "Move Static Members to Another Type...", which will open a dialog for selection options.

Dialog sample (subject to change)

Initially, a generated name of a new type will be provided, and the member that the user triggered the refactoring on will be automatically selected out of a list of all static members in the current type. We will notify the user that this type does not already exist, and therefore a new type will be created.

The user can use the dropdown to select or simply type the name of an existing type in the current namespace or project. The user can also select other static members, or use the convenience buttons to select all static members, deselect all static members, and select members that the current selected members depend on.

Pressing "OK" will perform the refactoring, removing the member (and its body if there is one) and adding it to either the selected existing type, or a new type in the same namespace with the provided name in a new class.

Notes

• We will not support the user being able to decide the name of the new file of a created type, the file name will be autogenerated. The user can rename the file after the refactoring is complete, through other tools.
• We may support movement to different namespaces/projects in the future. Right now we will support moving within a nested namespace, but not outside of the namespace from which you triggered the refactoring.

[Soreloser2]

Feature checklist:

• Dialog Box
  • Member Selection
  • Destination Selection
    • Selection of a new type using a text box
    • Selection of a new or existing type using dropdown options
  • Create Options after submission
• Implementation
  • New Type
  • Existing Type
  • Refactoring source document usages
  • Refactoring other usages
• Testing
  • Write Cases for implementation
  • Write Cases for selection
  • Write Cases for dialog options/UX

[CyraxSputnik]

Wow!!! This seems really cool!!!

I imagine is way harder to implement this using non static members, but would be not only an epic feature, should be mythic

[CyraxSputnik]

This refactoring using non-static members could create a new class passing all the related members in the constructor. Maybe ¯_(ツ)_/¯

[Soreloser2]

The feature to move to a new type is scheduled for release on 17.1-preview1. A draft PR containing some code for moving to an existing type is linked directly above; feel free to take a look 😄

[Soreloser2]

This refactoring using non-static members could create a new class passing all the related members in the constructor. Maybe ¯_(ツ)_/¯

Good idea, that's definitely a route to consider. I'd imagine it might be difficult to refactor other references to the moved members, as we might need to create multiple lines to construct the new class and then access the moved member.

Another option, specifically for methods, would be to convert them to extension methods, with the added first parameter being an instance of the class you're moving from. This might get a little funky with the refactoring inside the method itself, as we'd need to requalify all the member accesses to use the new instance. However, other references to the method wouldn't change, as the method invocation would stay the same.

[Soreloser2]

Closing as all the checkbox points for this feature have been created and merged. Moving to existing classes should be in 17.4 with #61519