What's an assembly identity?

Question

(Let's assume I only have a single default appdomain for this question)

Apparently Assembly.LoadFrom() can lead to multiple assemblies of the same name, version and content to be loaded even if just their paths are different. This seems to go against what is said here:

"At assembly-bind time, the components of the assembly display name determine identity". (http://blogs.msdn.com/b/suzcook/archive/2003/07/21/57232.aspx)

Because if the identities are the same, why would .NET load it into the process a second time? It seems there are two different kinds of identities.

From that blog post what also doesnt make sense is this:

"Not all of the components matter in all cases. If the assembly is not strongly-named, then the version is ignored for binding. But, if it is strongly-named, the entire version in the assembly reference needs to match the found assembly."

How does this make sense with what is said here:

"When this feature is enabled, strong names are not validated for correctness when the assembly is loaded. The default is true" (http://msdn.microsoft.com/en-us/library/cc679069(v=vs.90).aspx)

So strong names aren't validated at all which would make what Suzanne wrote in her blog post incorrect. Or what exactly is meant by "validation"? I think all of this boils down to a complete misunderstanding of assembly identity. I dont understand where and why and how an assembly identity matters in what ways.

Answer 1

Crash course in assembly identity: An assembly has a name and version, so far so straight forward. An assembly also has a culture; the implementations for different cultures may for example format date strings differently, and while they may have the same name and same version they do not do exactly the same thing. The public key token is part of a weak security measure to keep different publishers from producing assemblies with colliding identities.

Why would .NET load an assembly into the same App Domain multiple times?

Because the assembly is loaded in different load contexts. There is a context corresponding to default resolving behavior, a context to which copies loaded from a file path, and a context for other situations such as when the assembly is loaded from bytes in an assembly resolver. This behavior has been criticized since the types from assemblies with the same identity but in different contexts are treated as completely different types. See this MSDN article and this blog post:

https://msdn.microsoft.com/en-ie/magazine/dd727509%28en-us%29.aspx#id0400031

http://www.pabich.eu/2009/07/how-many-times-can-you-load-assembly.html

What does Suzanne Cook mean by validation? As a security mechanism (which has proven to be weak and easily broken) there is a private strong name key and a corresponding public key. The public key appears in the manifest of the DLL. The DLL is signed using the private key and the signature appears somewhere in the PE file - the PE header points to this information. A short form of the public key becomes the public key token. This ensures that only the publisher who holds the private key can produce binaries with a particular public key token, although this has security issues. This mechanism prevents assembly identity collisions between different publishers. Full trust assemblies have other signing mechanisms which ensure their authenticity. As an optimization, you can bypass checking the strong name signature since it is assumed fully trusted publishers won't attempt to collide assembly identities with each other. See more in this Microsoft doc:

https://docs.microsoft.com/en-us/dotnet/framework/app-domains/how-to-disable-the-strong-name-bypass-feature

Bonus question: I want a strong security mechanism so that my customers can really trust my assemblies. I might even want to verify that components of my application are really published by me to prevent reverse engineering, licensing avoidance, etc. How do I do this?

SHA256 Authenticode signatures are the latest and greatest in signing any PE file, be it a managed assembly or an unmanaged binary. This is not a replacement for the public key token. The public key token is important for establishing assembly identity. The Authenticode signature is important for verifying assembly authenticity.

https://blogs.msdn.microsoft.com/ieinternals/2011/03/22/everything-you-need-to-know-about-authenticode-code-signing