.

Rob: in the .NET world the identity of a type includes the assembly in which it is defined. Therefore in your example above there are two enum types named MyNamespace::MyEnum: the first is from assembly dll2 and the second is from dlltest and as far as the CLR is concerned these are two completely different types.

The correct solution is to define the enum in one assembly, say dll2, and then to reference it from the other assemblies: exactly the same as your reference the type dll2

Rob: in the .NET world there is not a 1-1 mapping between assemblies and namespaces: in fact there is a many-many mapping. An assembly can contain many namespaces and a namespace can be spread over many assemblies.

A good model here is the Base Class Library that ships with the CLR.

You have mscorlib.dll - this is assembly that contains all the common types: System::Object, System::String, etc. Every other .NET assembly refers to this assembly and references the definitions of one or more these types.

The BCL also comes with other assemblies like System.Data.dll (which contains classes specifically for handling data access), System.Net.dll (which contain networking classes) and System.Windows.Forms.dll (which contains classes related to forms).

So my advice would that if your applications have a set of common classes that they shared then you should put these classes into a common assembly that can then be referenced by all the applications.

Note: this only works for 'managed' types: for native types you still need to use the usual C++ method of including a header file.