Bug in Move Type to Namespace refactoring - usings not added for namespaces in same file

[bernd5]

Version Used: Visual Studio 16.9.0 Preview 3.0

Sample Code:

using System;

namespace Tests
{
    internal class Foo
    {
        public static int Do(Inner.Data d) => 42;
    }
}

namespace Tests {
    namespace Inner
    {
        public class App
        {
            static void Main()
            {
                Console.WriteLine(Foo.Do(new Data()));
            }
        }
        public class Data { }
    }
}

Steps to Reproduce:

1. Move type Foo to Namespace Something.Else

Expected Behavior:
Working Code

Actual Behavior:
Compile Error

Code after refatoring:

using Something.Else;
using System;

namespace Something.Else
{
    internal class Foo
    {
        public static int Do(Inner.Data d) => 42;
    }
}

namespace Tests
{
    namespace Inner
    {
        public class App
        {
            static void Main()
            {
                Console.WriteLine(Foo.Do(new Data()));
            }
        }
        public class Data { }
    }
}

Expected Code:

using Something.Else;
using System;
using Tests.Inner;

namespace Something.Else
{
    internal class Foo
    {
        public static int Do(Data d) => 42;
    }
}

namespace Tests
{
    namespace Inner
    {
        public class App
        {
            static void Main()
            {
                Console.WriteLine(Foo.Do(new Data()));
            }
        }
        public class Data { }
    }
}

[bernd5]

PR-Merge: #30896 (comment)
(The error is not there but it's the IDEs entry point...)

It works if all types are fully qualified

[ryzngard]

Should be fairly easy to fix, we can take this in 16.10. Marking help wanted in case anyone wants to take it before I get to it.

[bernd5]

Thanks for your response. I'm not sure how easy or difficult it is to fix. But the issue seems to be that partially qualified names are not handled correctly.
With just adding a using it is possible to get a name-conflict which would require full-qualification or a using declaration inside a namespace declaration.
It sounds easier as it is...

[ryzngard]

@bernd5 agreed in some cases it could be complex, but not too bad. We can find references in current doc, fully qualify, add using to the new namespace, and use simplifier to remove unnecessary qualifications and namespace. References outside current doc should already be fixed

[bernd5]

Btw.: is it possible to access those refactorings from the public roslyn API surface?

[CyrusNajmabadi]

Btw.: is it possible to access those refactorings from the public roslyn API surface?

Yes. You can use VS's ISuggestedActionsSourceProvider to query for Roslyn's provider that exposes our code fix and code refactoring provideers (ISuggestedActionsSource). You can call GetSuggestedActions on that source to get all our suggestions.

[bernd5]

Do you know where to find the implementation of the "move namespace" SuggestionAction? I want to move some classes (ClassDeclarationSyntax / ITypeSymbol) to a different namespace.
Do you have a link to a sample on how to get suggestions by code?

[ryzngard]

@bernd5 what are you trying to do? That code doesn't have a public API.

[bernd5]

I have a huge library with a massive amount of types. If certain criteria are met I would like to move some of them to another namespace.
I have started with my own CSharp-Syntax-Rewriter - but I would generally avoid to "reinvent the wheel" all over again and use a standard solution for this task.
The really complex part here is the adjustment of non-qualified names and the handling of using clauses.

[bernd5]

Even the API / rewriter is not public - I could imagine to use the assembly :-).

[CyrusNajmabadi]

This is not a supported scenario. You could certainly look at teh code we've written and copy/paste for your own needs as appropriate. But we don't expose out individual APIs to accomplish this stuff (primarily because these APIs change all the time and we don't want to be locked into supporting something forever that limits our ability to respond to changes/issues in an efficient fashion).