Namespace and class with the same name?

I'm organizing a library project and I have a central manager class named Scenegraph and a whole bunch of other classes that live in the Scenegraph namespace.

What I'd really like is for the scenegraph to be MyLib.Scenegraph and the other classes to be MyLib.Scenegraph.*, but it seems the only way to do that would be to make all the other classes inner classes of Scenegraph in the Scenegraph.cs file and that's just too unwieldy.

Instead, I've organized it as Mylib.Scenegraph.Scenegraph and MyLib.Scenegraph.*, which sort of works but I find Visual Studio gets confused under some conditions as to whether I am referring to the class or the namespace.

Is there a good way to organize this package so it's convenient for users without glomming all my code together in an unmaintainable mess?


I don't recommend you to name a class like its namespace, see this article.

The Framework Design Guidelines say in section 3.4 “do not use the same name for a namespace and a type in that namespace”. That is:

namespace MyContainers.List 
{ 
    public class List { … } 
}

Why is this badness? Oh, let me count the ways.

You can get yourself into situations where you think you are referring to one thing but in fact are referring to something else. Suppose you end up in this unfortunate situation: you are writing Blah.DLL and importing Foo.DLL and Bar.DLL, which, unfortunately, both have a type called Foo:

// Foo.DLL: 
namespace Foo { public class Foo { } }

// Bar.DLL: 
namespace Bar { public class Foo { } }

// Blah.DLL: 
namespace Blah  
{   
using Foo;   
using Bar;   
class C { Foo foo; } 
}

The compiler gives an error. “Foo” is ambiguous between Foo.Foo and Bar.Foo. Bummer. I guess I’ll fix that by fully qualifying the name:

   class C { Foo.Foo foo; } 

This now gives the ambiguity error “Foo in Foo.Foo is ambiguous between Foo.Foo and Bar.Foo”. We still don’t know what the first Foo refers to, and until we can figure that out, we don’t even bother to try to figure out what the second one refers to.


Giving the same name to the namespace and the class can confuse the compiler as others have said.

How to name it then?

If the namespace has multiple classes then find a name that defines all those classes.

If the namespace has just one class (and hence the temptation to give it the same name) name the namespace ClassNameNS. This is how Microsoft names their namespaces at least.


I would suggest that you follow the advice I got on microsoft.public.dotnet.languages.csharp to use MyLib.ScenegraphUtil.Scenegraph and MyLib.ScenegraphUtil.*.


Even though I agree with other answers in that you should not name your class the same as your namespace there are times in which you cannot comply with such requirements.

In my case for example I was not the person making such a decision therefore I needed to find a way to make it work.

So for those who cannot change namespace name nor class name here is a way in which you can make your code work.

// Foo.DLL: 
namespace Foo { public class Foo { } }

// Bar.DLL: 
namespace Bar { public class Foo { } }

// Blah.DLL: 
namespace Blah
{
    using FooNSAlias = Foo;//alias
    using BarNSAlias = Bar;//alias
    class C { FooNSAlias.Foo foo; }//use alias to fully qualify class name
}

Basically I created namespace "aliases" and that allowed me to fully qualify the class and the Visual Studio "confusion" went away.

NOTE: You should avoid this naming conflict if it is under your control to do so. You should only use the mentioned technique when you are not in control of the classes and namespaces in question.


CA1724: Type Names Should Not Match Namespaces ...

Basically, if you follow Code Analysis for proper coding this rule says to not do what you are trying to do. Code Analysis is very useful in helping you find potential issues.