How does the .NET runtime determine that two types are the same?

Question

I have assembly A that depends (statically) on type T (reference type, a class) in assembly B.

I do not own assembly A but I do own assembly B. T unfortunately is a real type (not an interface) but luckily A uses reflection to discover its members.

I want to be able to create dynamically B (and T). The only important item is that I need to be sure that the "B and T" dynamically created (not their members) are "equivalent" tho those that were statically compiled when A was compiled.

1. I can use reflection Emit to create B and T. No problem.
2. I can write B.dll to disk
3. If A was compiled against this B.dll then I can dynamically change T, no problem
4. However if A was compiled against a equivalent (hand written B and T) then the T' in A would have the same assembly name and type name but it would not be considered equal to the one dynamically created.

I assume that the reason is the GUID property on the type. When I write B.dll to disk the T type has the same GUID than the one I can create dynamically (even if I change its members). However the "otherwise equivalent" hand-written type does not share the same GUID.

In summary the GUID is the same if the dll comes from the dynamically created but is different from the one statically created. The GUID is the same every time (even if I recompile). The GUID is the same if I change the content of the dynamic Type.

How does the runtime determine if two types are the same? How is this GUID created? It uses this GUID and/or something else? Is it possible to assign this GUID in my dimamic assembly to match the one in assembly A?

Can this GUID be examined statically (I was not able to see it with Reflector or ildasm).

NOTE: Assume assemblies are not signed.

Answer 1

The .NET runtime uses the assembly name, version, strong name (if present), and in some cases the culture to locate referenced assemblies. If an assembly A references another assembly B it is possible to replace B with another assembly if the mentioned properties are exactly the same. If B has a strong name you can only create another assembly with the same strong name if you own the key file that was used to sign the assembly.

AFAIK, the Type.GUID property is only used when your types are registered for COM use. It works with the GuidAttribute class. Hence, Type.GUID has nothing to do with the "identity" of a type.

You can read more about how the runtime locates assemblies here: http://msdn.microsoft.com/en-us/library/yx7xezcf.aspx