CODEWITHSUNDEEP
c#
ZZZ
ZZZ

Reputation: 2802

Internal classes having the same namespaces but in different assemblies?

Basically I have a CS file defining an internal class, then I copy to various of CS projects. And the assemblies of these CS projects will be loaded in an application. The program seems to be running just fine.

However, having multiple classes with the same class name in the same namespace make me feel uneasy even if they are internal within each assembly.

Is a class uniquely identified through class name, namespace as well as assembly in an AppDomain?

Upvotes: 5

Views: 1324

Answers (3)

Jimmy
Jimmy

Reputation: 28446

Yes, the CLR uses the assembly to identify each type. If you compile a simple Hello World app and look at the IL:

.method private hidebysig static void  Main(string[] args) cil managed
{
  .entrypoint
  // Code size       13 (0xd)
  .maxstack  8
  IL_0000:  nop
  IL_0001:  ldstr      "Hello world"
  IL_0006:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_000b:  nop
  IL_000c:  ret
} // end of method Program::Main

You can see how System.Console is referred to by including the assembly, namespace, and class names. However, if you are referring to a type in the same assembly, the assembly name can be implied, e.g.:

.method private hidebysig static void  Main(string[] args) cil managed
{
  .entrypoint
  // Code size       13 (0xd)
  .maxstack  8
  IL_0000:  nop
  IL_0001:  ldstr      "Hello world"
  IL_0006:  call       void ConsoleApplication1.Foo::Write(string)
  IL_000b:  nop
  IL_000c:  ret
} // end of method Program::Main

Upvotes: 1

Eric Lippert
Eric Lippert

Reputation: 660533

Is a class uniquely identified through class name, namespace as well as assembly in an AppDomain?

Short answer: yes.

Longer answer:

There are a few subtle points to consider.

First, from the CLR perspective there is no such thing as a "namespace". The name of the string type is System.String as far as the CLR is concerned. So it is more accurate to say that from the CLR perspective, a type is uniquely identified by its name and assembly.

Second, types may be nested. So types are actually uniquely identified by their name, containing type (if there is one) and assembly.

Third, types may be generic. Foo.Bar and Foo.Bar<T> are different types. So types are identified by their name, containing type, assembly, and generic arity.

Fourth, and this is the weird one, the CLR considers types in assemblies loaded with Load different than types in the same assembly loaded with LoadFrom. You can end up with situations where the CLR tells you that type Foo in assembly Bar is not compatible with type Foo in assembly Bar, and boy, is that confusing.

Upvotes: 8

T McKeown
T McKeown

Reputation: 12857

While it makes things confusing all your internal classes only exist in their respective assemblies so they are autonomous and will not be seen by the other classes in the other assembly.

But from a maintenance and simplicity perspective it should be put at the top of the house keeping tasks.

Upvotes: 1

Related Questions