The short version is this: ALWAYS place every bit of your code, every class, every struct, inside a namespace.

The long version follows.

In library dll written for Microsoft.net, there is a helper class called SupportClass, that is not inside a namespace. This is causing serious issues in our automated build system that I finally, after about 4 hours of trial and error, isolated to two dll’s.

We’ll call them Awrecka.dll and Chavelle.Directory.Ldap.dll

We use Awrecka.dll for several production sites as well as a few sites under development. When updating this 3^{rd party dll to the latest version, our build failed with the error:}

[filepath]\Ldap\DirectoryConnection.cs(1005,24): error CS0122: 'SupportClass' is inaccessible due to its protection level

SupportClass is in Chavelle. and is public. I had to add one modified file at a time, to the build system, until the successful builds became a failed build. When I added the updated library dll, the build failed. I then inspected further to find the problem.

"SupportClass" is not a unique name. In fact, both Awrecka and Chavelle have a "SupportClass". They are both declared with no namespace and therefore are both in the global namespace, causing a collision. We use Chavelle's support class in some of our code. Since this awrecka.dll comes alphabetically before Chavelle, csc.exe tried to access your support class first and failed when attempting to execute an enterprise build

To crrect this, both should place this SupportClass inside an Awrecka or Chavelle namespace by surrounding the class definition with

{

...your code

}

or

{

...your code

}

This will help prevent other clients from experiencing the immense pain I did this morning.

Why is it bad to exclude a namespace?

If you do not explicitly declare one, a default namespace is created. This unnamed namespace, sometimes called the global namespace, is present in every file. Any identifier in the global namespace is available for use in a named namespace. Namespaces are implicitly public. Therefore, by marking your class as internal, yet placing it in the global namespace, you've created a publically visible class that is not publically accessible. It can, and did, create a compilation collision and failure.

Using Visual Studio, the class view will help get a clear picture of your namespace and class structure. Since you publish your dll externally from your comapny, the implications and responsibility of code organization and visibilty are increased.

references:

C# Language Specification

9.2 Namespace declarations

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csspec/html/vclrfcsharpspec_9.asp

C# Programmer's Reference

namespace

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/html/vclrfnamespace.asp