Assemblies and Version Control

Isolated assemblies

An assembly that is isolated is only accessible to the application that provides it. It is completely internal to it. This simplifies version control since you don't have other application dependencies except the owner's to deal with. However, .NET version control can even assist here to permit upgrade patches of an application's constituent assemblies.

Shared assemblies

Sharing an assembly is an explicit decision made by the application. Assemblies that do this support .NET's "side-by-side" approach and are placed into a global system-wide storage. Since they are to be shared, an additional constraint is placed on assembly names: they must be globally unique. Also, to maintain the integrity of assembly upgrades, .NET prevents "name spoofing" - attempts for a 3rd party to provide an "upgrade" to someone else's assembly. Only the originator has the power to create new versions of an assembly.

Versioning

Assembly version numbers use a "major/minor/build/revision" version format. To .NET, identical assemblies with differing major and minor numbers are "incompatible", whereas identical assemblies with differing build and revision numbers are considered compatible. .NET will automatically load the highest build/revision assembly on behalf of an application. However, through overriding configuration files, an assembly or application can request a specific version number of an assembly to work with.

References: D