Do not include folder name to namespace

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

When a new class is created under a folder, Visual studio automatically appends the folder name to the namespace. This is very difficult to catch in codereviews and in some common libraries changing this later becomes extremely hard.

Please provide an easy way to disable this in csproj.

---

Original Comments

Visual Studio Feedback System on 6/23/2020, 00:34 AM:

We have converted this feedback item from problem to idea. This change was done to better reflect the feedback's nature.

Visual Studio Feedback System on 6/24/2020, 02:55 AM:

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.

[KirkMunro]

How I would like to see this implemented:

1. Add an Include in Namespace boolean property to folders that indicates whether the folder is purely for organizational purposes or should be reflected in the namespace of classes or interfaces created in that folder. Default this to true since that is the current behavior.
2. When adding a new class or interface to a folder, if the Include in Namespace property is set to false, do not include that folder name as part of the namespace.
3. If a folder has Include in Namespace set to false, show it as a different color so that visually you can easily identify which folders are part of the namespace, and which are not, when looking at the structure in the solution explorer.
4. Update the context menu/folder creation options to include New namespace folder and New organizational folder to allow for direct creation of the specific type of folder you want without having to manually tweak the settings on that folder.

[hamarb123]

I would like this feature. I think all that is necessary is an option on the folder in the properties tab that turns it off (thus skipping this folder as a part of namspace naming). This would also be the default option for sub-folders of a folder with it off.

[Ziflin]

Is there not an option to disable this at the project level? This is extraordinarily irritating for those of us that do not used folders as namespaces.

[CyrusNajmabadi]

I don't believe there is. This appears to represent a small minority position. We'll have to weigh the cost of doing this, versus everything else, versus the size of the ecosystem that benefits from it.

[davidwengier]

Related: dotnet/project-system#5372

[Balkoth]

I would like to see this too, in smaller projects, it sometimes makes sense to organize files into folders, but use one namespace for all objects.

[CodeAngry]

I would like to see this too, in smaller projects, it sometimes makes sense to organize files into folders, but use one namespace for all objects.

example: Organizing models in a meaningful folder structure that does not participate in namespace naming but keeps them all in the Models namespace.

[justinefication]

I don't believe there is. This appears to represent a small minority position. We'll have to weigh the cost of doing this, versus everything else, versus the size of the ecosystem that benefits from it.

I don't think this represent a small minority. JetBrains Rider provided an option for this in a much more sophisticated way. Frankly if I can afford it, I will ditch Visual Studio with no hesitation. All you need to do is to provide a boolean option in the Solution Explorer's Folder Properties, say NamespaceProvider that determines whether the folder name will be included in the namespace or not.

[CyrusNajmabadi]

@aLexiusxx this is on our backlog. So if you wanted to contribute the fix of "All you need to do is...", We would likely take it. Thanks!

[FacioRatio]

I've wanted this for 20 years. Maybe it'll happen after I retire. It has just never made sense for a namespace to be tightly coupled to a file's location in a filesystem. They have dick-all to do with one another. All I want is for a new file to always just have a single namespace that is specified in the .csproj file. That would solve it for 95% of us.

[CyrusNajmabadi]

@FacioRatio see #45494 (comment).

[CSEliot]

I've wanted this for 20 years. Maybe it'll happen after I retire. It has just never made sense for a namespace to be tightly coupled to a file's location in a filesystem. They have dick-all to do with one another. All I want is for a new file to always just have a single namespace that is specified in the .csproj file. That would solve it for 95% of us.

Spoken like a true vet! I am vehemently opposed to close-sourced tech like Rider but it's "namespace-provider" folder option is AWESOME!!!

[vitasystems]

I have been writing code since .NET 1.0 which was released in 2002... so for about 23 years now.
And I can say that the most annoying "feature" of Visual Studio has been this Bug.
A developer should be in full control of the namespacing and the namespacing strategy.
Organizing namespaces tightly coupled to folder names is the perfect example of an anti-pattern driving you mad into the folder hell.
Any one who has written serious code knows that when you have millions of lines of code this whole "folder feature" is nothing but an obstacle.
The right way in the dream world would be to allow a developer to include a "Namespace Provider" class in a solution or project that "resolves" the namespace when adding a new class, and Visual Studio should just by default provide their "Microsoft.DefaultNameSpaceResolver" which would be overriden by the specific "MyCompanyCompliantNameSpaceResolver" provided by the developer.
Namespacing is one the most important parts of architectural design and I have always felt this has been overlooked and often responded to with a "patronizing" answer like "Why dont you do it yourserlf"... Well because we are not the ones developing Visual Studio... We are the ones using it.

Some other answers I have gotten are "This is by design", "This is a feature".

I would say this "feature" is on the top 2 "most horrible visual studio bugs that were never fixed" along with the "Recent" mixing projects and solutions in the same menu.

[CyrusNajmabadi]

@vitasystems see #45494 (comment)

and I have always felt this has been overlooked and often responded to with a "patronizing" answer like "Why dont you do it yourserlf"..

I don't know anyone who has said this. There is an open discussion with teh project system on this feature here: dotnet/project-system#5372

Some other answers I have gotten are "This is by design", "This is a feature".

These issues remain open and we are interested in this space. However, as we have very limited resources, this is on the backlog as we do not have any more budget to spend here.

along with the "Recent" mixing projects and solutions in the same menu.

I do not know what this is referring to. If there is an issue with Roslyn, please file it so we can take a look.

[FacioRatio]

One of the ten most profitable companies in the world has "very limited resources" to fix something that's been requested for over two decades, folks.

[CyrusNajmabadi]

One of the ten most profitable companies in the world has "very limited resources" to fix something that's been requested for over two decades, folks.

Yes. That's correct. We have a small number of devs on the team, and many thousands of customer requests spanning decades.

As such, like virtually all development teams on the planet, we have work we allocate time and resources for, and work that goes on the backlog.

Note: as this is open source, we welcome community involvement. Many issues that do not rise to the level of getting info a milestone are worked on when the community had members who feel like the issue is important enough to them to work on.

[vitasystems]

One of the ten most profitable companies in the world has "very limited resources" to fix something that's been requested for over two decades, folks.

Yes. That's correct. We have a small number of devs on the team, and many thousands of customer requests spanning decades.

As such, like virtually all development teams on the planet, we have work we allocate time and resources for, and work that goes on the backlog.

Note: as this is open source, we welcome community involvement. Many issues that do not rise to the level of getting info a milestone are worked on when the community had members who feel like the issue is important enough to them to work on.

Not trying to beat on a dead horse here. But we pay for visual studio. I personally pay for multiple subscriptions.

And honestly I have seen many "features " that are completely useless about "fonts" and other things that dont help anyone or that are buried deep in the options.

And telling your customers to go and "develop it yourselves" is not good for business.

This is why I will be moving away from visual studio.

[CyrusNajmabadi]

Not trying to beat on a dead horse here. But we pay for visual studio. I personally pay for multiple subscriptions.

Sure. But that doesn't change that there are limited resources to make changes, and thousands of requests for changes. So stole features will naturally not make it off the backlog.

And honestly I have seen many "features " that are completely useless about "fonts" and other things that dont help anyone or that are buried deep in the options.

I don't know which features you are referring to. Roslyn doesn't generally work with fonts. So it sounds like you may be talking about features written by other teams.

And telling your customers to go and "develop it yourselves" is not good for business.

Many customers and community members have contributed lots of features to roslyn over the years. This has allowed them to get the features they want, without having to wait for such a feature to make it off our backlog. Being open source has been great for us and for them. It's win/win :-)