Roslyn: User-defined root namespaces for "separate import directive groups"

[vsfeedback]

_This issue has been moved from a ticket on Developer Community._

---

Visual Studio (and .editorconfig) support a setting called "separate import directive groups" that inserts newlines between logical blocks of `using`/`Imports` statements. The example shown in the .editorconfig documentation is that it turns this:

using System.Collections.Generic;
using System.Threading.Tasks;
using Octokit;

.. into this:

using System.Collections.Generic;
using System.Threading.Tasks;

using Octokit;

I would like to request an extension to this feature that allows the configuration of custom "root namespaces". The company I work for creates a great number of separate libraries for various projects, and these are all placed within a root namespace, call it `Foo`. So, even with "separate import directive groups" on, a file might look like this (entirely fictional namespaces :-):

using System;
using System.Collections;

// Note that the following are not semantically separated into groups, because
// the current processor is only comparing "Foo" for the purpose of deciding
// groupings.
using Foo.Common;
using Foo.GronkulatorService.Contracts;
using Foo.GronkulatorService.Model;
using Foo.TextProcessing;
using Foo.TextProcessing.Markdown;
using Foo.TextProcessing.RegularExpressions;

using Functional;

using Nancy;
using Nancy.Bootstrapper;
using Nancy.Json;
using Nancy.Hosting.Aspnet;

I want the ability to configure `Foo` as a "root namespace", so that the different second-level namespace names produce separate groups:

using System;
using System.Collections;

using Foo.Common;

using Foo.GronkulatorService.Contracts;
using Foo.GronkulatorService.Model;

using Foo.TextProcessing;
using Foo.TextProcessing.Markdown;
using Foo.TextProcessing.RegularExpressions;

using Functional;

using Nancy;
using Nancy.Bootstrapper;
using Nancy.Json;
using Nancy.Hosting.Aspnet;

Ideally, this feature would allow any number of "root namespaces" to be defined, and each one could specify as many components of prefix as it wanted, and any imports sharing that prefix would get separated out by the next component, whatever that was.

---

Original Comments

Dada Huo [MSFT] on 9/16/2020, 02:41 AM:

Thank you for your feedback! Does this reproduce for all project or specific project? If it’s reproduce with the specific project, which project do you use? It would be very helpful if you can provide a screenshot of this issue. Thanks for your help!

Jonathan Gilbert on 9/16/2020, 08:10 AM:

I am very disappointed by your reply. This is a feature suggestion, not a bug.

Dada Huo [MSFT] on 9/16/2020, 07:06 PM:

Thank you for taking the time to provide your suggestion.  We will do some preliminary checks to make sure we can proceed further.  We’ll provide an update once the issue has been triaged by the product team.

Feedback Bot on 9/17/2020, 10:41 AM:

Thanks for creating this issue! We figured it’s covering the same as another one we already have. Thus, we closed this one as a duplicate. We’ve transferred all votes from this ticket to the other one. For more information, see also our issue reporting guidelines.

Happy coding!

Jonathan Gilbert on 9/17/2020, 11:32 AM:

Uhh, what?? That issue doesn't seem even remotely related to this one.

Feedback Bot on 9/17/2020, 11:44 AM:

Your suggestion has been queued up for prioritization. Feature suggestions are prioritized based on the value to our broader developer community and the product roadmap. We may not be able to pursue this one immediately, but we will continue to monitor it for community input

[logiclrd]

The migration process wasn't very careful about newlines, which is rather important in this case. Here is the original feature suggestion text:

---

Visual Studio (and .editorconfig) support a setting called "separate import directive groups" that inserts newlines between logical blocks of using/Imports statements. The example shown in the .editorconfig documentation is that it turns this:

using System.Collections.Generic;
using System.Threading.Tasks;
using Octokit;

.. into this:

using System.Collections.Generic;
using System.Threading.Tasks;

using Octokit;

I would like to request an extension to this feature that allows the configuration of custom "root namespaces". The company I work for creates a great number of separate libraries for various projects, and these are all placed within a root namespace, call it Foo. So, even with "separate import directive groups" on, a file might look like this (entirely fictional namespaces :-):

using System;
using System.Collections;

// Note that the following are not semantically separated into groups, because
// the current processor is only comparing "Foo" for the purpose of deciding
// groupings.
using Foo.Common;
using Foo.GronkulatorService.Contracts;
using Foo.GronkulatorService.Model;
using Foo.TextProcessing;
using Foo.TextProcessing.Markdown;
using Foo.TextProcessing.RegularExpressions;

using Functional;

using Nancy;
using Nancy.Bootstrapper;
using Nancy.Json;
using Nancy.Hosting.Aspnet;

I want the ability to configure Foo as a "root namespace", so that the different second-level namespace names produce separate groups:

using System;
using System.Collections;

using Foo.Common;

using Foo.GronkulatorService.Contracts;
using Foo.GronkulatorService.Model;

using Foo.TextProcessing;
using Foo.TextProcessing.Markdown;
using Foo.TextProcessing.RegularExpressions;

using Functional;

using Nancy;
using Nancy.Bootstrapper;
using Nancy.Json;
using Nancy.Hosting.Aspnet;

Ideally, this feature would allow any number of "root namespaces" to be defined, and each one could specify as many components of prefix as it wanted, and any imports sharing that prefix would get separated out by the next component, whatever that was.

[CyrusNajmabadi]

Dupe of https://github.com/dotnet/roslyn/issues/44052. The work there (if we go ahead with it), would cover this. Closing out.