11

I find that sometimes I have the need to have multiple namespaces in a project I'm working on - are there any problems that may arise from having multiple namespaces in the same project?
The alternative is obviously having multiple projects (per namespace) in the Solution.

Acidic
  • 6,154
  • 12
  • 46
  • 80
  • 2
    "The alternative is obviously having multiple projects in the Solution." - that is usually a better method. – Mitch Wheat Mar 03 '13 at 01:42
  • @MitchWheat It seems to be the more "orderly" approach, but all it really does is clutter my solution. A bigger problem is that it produces multiple files on compilation. – Acidic Mar 03 '13 at 01:44
  • But that's a completely different problem with a different solution. – Mitch Wheat Mar 03 '13 at 01:44
  • @MitchWheat I know it is possible to use ILMerge or similar tools, but is it not easier to simply avoid the problem altogether? – Acidic Mar 03 '13 at 01:45
  • 1
    Non-trivial projects are going to have multiple, nested namespaces, and non-trivial applications are going to have multiple projects. It's no big deal. Don't stuff everything into one namespace or one project and think that you're being organized. – Anthony Pegram Mar 03 '13 at 01:45
  • Possible duplicate: http://programmers.stackexchange.com/questions/145344/layers-logical-seperation-vs-physical – P.Brian.Mackey Mar 03 '13 at 01:46
  • @AnthonyPegram I use nested namespaces extensively, so that's not really what my question is about. It's about completely separate namespaces with possibly non-visible `internal` code - something that isn't possible with nested namespaces. – Acidic Mar 03 '13 at 01:48
  • 2
    Huh? `internal` means only accessible within the same assembly, not the same namespace – Tim Goodman Mar 03 '13 at 01:55
  • @TimGoodman oh, for some reason I was sure that `internal` was only visible to classes with the same root namespace. I checked it and you're correct... This question is rather pointless now. – Acidic Mar 03 '13 at 02:03

3 Answers3

13

Yes, it's fine. Often my namespaces align to the folder structure of the project. So the top-level namespace might be the same for the whole project, but there would be multiple sub-namespaces.

The purposes of namespaces are (1) organization and (2) avoiding naming collisions, not necessarily in that order. Whereas, separating things into multiple projects is more because you want multiple binaries or you want to share code between multiple solutions. These are somewhat orthogonal concerns.

Tim Goodman
  • 23,308
  • 7
  • 64
  • 83
2

Yes many classes to a single namespace. Many namespaces in a project is totally fine. It is cosmetic.

iefpw
  • 6,816
  • 15
  • 55
  • 79
1

The answer to this question, without getting into best practices, is that there won't be any technical problems from using multiple namespaces in one project.

However, visual studio only supports one base namespace, which is located in the project properties (right click properties in solution explorer on the project itself) and any time you create a new file, it will be created with this default namespace (if on root), or the default namespace plus whichever folder structure you have.

Not a problem per se, but you'll need to manually check each new C# file you add to the project and change the namespace accordingly if that particular file will not be using the default namespace for the project.

Dmitriy Khaykin
  • 5,238
  • 1
  • 20
  • 32