We Keep Coding

'Class' is a namespace but is used like a 'type'

First, this is not the same as the many highly upvoted questions on this exact topic unless I'm missing one of them. All of them point that the issue is I have a namespace with the same name as the class. This is not the case (but it was).
I started out creating a new console application called BatchResizer and put a couple of classes there, but then decided to move this into a class library, called BatchResizer.Components; I then renamed the original console application to BatchResizer.ConsoleRunner, changed all classes in that project to namespace BatchResizer.ConsoleRunner.[...], set the assembly name and default namespace to the same.
There is a class titled BatchResizer but there are no namespaces titled [...].BatchResizer in the project anymore, but when I do var batchResizer = new BatchResizer() I get the error that the namespace is used like a class. There are items named like BatchResizer.ConsoleRunner.[...] or BatchResizer.Components.[...], but nothing ending in BatchResizer.
I've tried "cleaning" and rebulding the project, deleting the .suo file, deleting the /bin folder of all projects in the solution, and I've went through every class in all related projects for namespace collisions.

BatchResizer is still a namespace name, though. If it's also the same name as a class, you'll have to be more explicit:
var batchResizer = new Components.BatchResizer();
You could also add a using statement within your namespace:
namespace BatchResizer.ConsoleRunner
{
using Components;
internal class Program
{
private static void Main(string[] args)
{
var batchResizer = new BatchResizer();
}
}
}
If you want to get a bit geeky, then the C# 5.0 spec has this to say:
9.2 Namespace declarations
...The qualified-identifier of a namespace-declaration may be a single identifier or a sequence of identifiers separated by “.” tokens. The latter form permits a program to define a nested namespace without lexically nesting several namespace declarations. For example,
namespace N1.N2
{
class A {}
class B {}
}
is semantically equivalent to
namespace N1
{
namespace N2
{
class A {}
class B {}
}
}
So even if, as you say, no class is declared in the namespace BatchResizer, BatchResizer is declared as a namespace.

First, this is not the same as the many highly upvoted questions on this exact topic unless I'm missing one of them. All of them point that the issue is I have a namespace with the same name as the class. This is not the case (but it was).
BatchResizer may not be a 'final' namespace, but it' still a namespace
Namespace : Foo.BatchResizer.Components
Foo.BatchResizer.ConsoleRunner
Class : Foo.BatchResizer

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.

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.

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

As others have said, it's a good practice to avoid naming a class the same as its namespace.
Here are some additional naming suggestions from an answer by svick to a related question "Same class and namespace name" on the Software Engineering Stack Exchange:
You're right that you shouldn't name the namespace the same as a type
it contains. I think there are several approaches you can use:
Pluralize: Model.DataSources.DataSource
This works especially well if the primary purpose of the namespace is
to contain types that inherit from the same base type or implement the
same interface.
Shorten: Model.QueryStorage
If a namespace contains only a small number of types, maybe you don't
need that namespace at all.
Make enterprisey: Model.ProjectSystem.Project
This can work especially for features that are important part of your
product, so they deserve their own name.

It happens when it's the main class of the namespace. So it's one motivation to put the namespace in a library, then the issue goes away if you add 'Lib' to the namespace name...
namespace SocketLib
{
class Socket
{

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.

Old post, but here I go with another idea that may help someone:
"...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."
This is really the better implementation for a bunch of scenarios. But, I do agree that having all that code on the same .cs file is annoying (to say the least).
You could solve it by making the base class a "partial class" and then, go on creating the inner classes on their own files (just remember that they'll have to declare the base class complement and then go on with the specific inner class for that file).
Something like...
Scenegraph.cs:
namespace MyLib
{
public partial class Scenegraph
{
//Scenegraph specific implementations
}
}
DependentClass.cs:
namespace MyLib
{
public partial class Scenegraph
{
public class DependentClass
{
//DependentClass specific implementations
}
}
}
I do think that this is the closer that you can get to having the clean implementation of inner classes while not having to clutter everything inside one huge and messy file.

Just Adding my 2 cents:
I had the following class:
namespace Foo {
public struct Bar {
}
public class Foo {
//no method or member named "Bar"
}
}
The client was written like this:
using Foo;
public class Blah {
public void GetFoo( out Foo.Bar[] barArray ) {
}
}
Forgiving the error GetFoo not returning the output instead of using the out parameter, the compiler could not resolve the data type Foo.Bar[] . It was returning the error: could not find type or namespace Foo.Bar .
It appears that when it tries to compile it resolved Foo as the class and did not find an embedded class Bar in the class Foo. It also could not find a namespace called Foo.Bar . It failed to look for a class Bar in the namespace Foo. The dots in a name space are NOT syntactic. The whole string is a token, not the words delimited by the dots.
This behaviour was exhibited by VS 2015 running .Net 4.6

Can I break encapsulation/data hiding with namespaces (.Net)

If I am making a .Net dll, is it possible to break encapsulation in any program that uses it, by creating a class with the same namespace?
For example, consider a DLL with the following code in it:
using System;
namespace MyDLL
{
internal class MyClass
{
internal void Stuff()
{
...
}
}
}
If I was to then create a project, and reference the DLL, would I be able to do something like the following?
using System;
using MyDLL;
namespace MyDLL
{
public class TheirClass
{
MyClass exposedClass = new MyClass();
exposedClass.Stuff();
}
}
I'm currently working on a project that will have a few abstract classes I want a user to be able to inherit, but I only want to certain features to be exposed.
Thanks in advance.

No, using the same namespace have no impact on data encapsulation nor any impact on visibility (private/protected/internal). Namespaces are syntactic sugar in C#, actual class names consist of namespace, name and assembly identity.
So in your particular case adding class with full name MyDLL.TheirClass{TheirAssembly} will not make MyDLL.MyClass{MyDLL} visible from TheirClass (since your class is internal and new class is from other assembly not marked as InternalsVisibleTo in your assembly).

Can you create private classes in C#?

This is a question for the .NET philosophers:
It is my understanding that Microsoft consciously denied use of private classes in C#. Why did they do this and what are their arguments for doing so?
I, for example, am building a large application that includes a reporting tool. This tool uses a lot of business objects that are used only within the reporting tool and not in other parts of the project. I want to encapsulate them for use only within the reporting tool itself.
Great decision is creating separate project in VS for this tool, and I'll do like that, but I'm interesting, what if I can't do this - for exmple our architecture wasn`t good enough, and we have big single project.
Behind "private class" I mean a class that can't be used in any other namespace, except its own.
My question was not - how can I simulate this, or do in another way. I'm just wondering, why not use private keyword with class keyword without any parent classes. I`m thinking there should be some reason, and I want to know it

Allowing classes to be private to a namespace would achieve no meaningful level of protection.
Any assembly in the world could simply reference your dll, and start writing code in your namespace which accesses your supposedly private classes.
I think that's possibly the answer you'd get from Microsoft.

There's a workaround for this, but you might not like it.
Instead of using a namespace to scope your classes, use a public static partial class:
Before:
namespace MyCompany.Foo {
class Bar { }
public class Baz { }
}
After:
namespace MyCompany {
public static partial class Foo {
private class Bar { }
public class Baz { }
}
}
This construct, like a namespace, can span multiple files in the same project. But unlike a namespace, it cannot "escape" from your project (other projects cannot define other members inside Foo).
There's an added advantage that you can have utility methods that seem to have no class for code inside Foo.
The disadvantage is that, to use your non-private classes outside of your fake namespace, you have to reference them inside Foo:
using MyCompany;
// ...
var baz = new Foo.Baz();
This can be mitigated by using an alias for the class:
using Baz = MyCompany.Foo.Baz;
// ...
var baz = new Baz();
But you'd have to do it for each non-private class that you want to use.
UPDATE
It's interesting to note that C# 6 will have static using statements, which could effectively improve this proposal to use a public static partial class as a "module". You would just "use" the "module" to access its types directly.
Hopefully, it will work like this:
using MyCompany.Foo;
// ...
var baz = new Baz();
Just as if Foo was a namespace.

You can create a private class, as a member of another type:
public class Outer {
// ...
private class Inner {
// ...
}
}
and Inner is only visible to members of Outer.
At the outermost level (i.e. in a namespace) private as per its definition would not make sense (since there is nothing to be private in). Instead use internal (visible to the containing assembly's members only).

You can define a private class, but it can only be used by its containing class.
If you want a class that is only visible within a particular assembly (DLL/EXE/etc.), then you should declare it as internal (Friend in VB)

True but you can get a pretty close simulation of this with internal classes and the internalsvisibletoAttribute if the namespace is split across multiple assemblies.
Also remember that a class within another can be private to the outer class. The outer class can be considered a namespace for this purpose.

So I guess you want to do this
namespace Baz
{
private class foo
{
private int _bar;
}
}
If yes. Then what is the purpose foo will server. At namespace can you be more restrictive than internal , and make any use of the class.If I could do this where will I use this .
That is why you have this compile time validation.
Now Inside a Public Class it makes sense to have a private class. I cannot explain it better this Private inner classes in C# - why aren't they used more often?.

Using a class file/reference it?

If you use a you assembly reference (myExample.dll), you add like this to the top
using myExample;
Now if you create a class file, how do you reference it?

Well, in your class file you have the following:
namespace myNamespace
{
public class MyClass
{
public void MyMethod() { }
}
}
Let's assume that you have this in an assembly named MyDll.dll. You'd use it as follows:
You add a reference to MyDll.dll within the solution explorer
You include the namespace with using myNamespace;
Then you can use your class doing MyClass test = new MyClass();
If you don't add the namespace like I said in 2., you'd use your class like:
myNamespace.MyClass test = new myNamespace.MyClass();

You want to add a using statement for whatever namespace you want to import. Go to the file and see what namespace it wraps the class you're interested in.

You just include the file when compiling the assembly.
You may have to add a using statement too.

Your question is somehow unclear.
When you define a new class, in another dll, it is enough to reference that dll.
Please note that you might be unable to access that class because of its accessors. Define your class with a public keyword.