.net - Assembly Loading Version Mismatch: Why is it loading?

Question

I have two assemblies: HelloWorld.exe and Hello.dll. The exe is the main assembly and the dll is being used by the main assembly.

I compiled both HelloWorld.exe (1.0.0) and Hello.dll (1.0.0). I placed the assemblies on a different folder.

I then changed the version of Hello.dll to 2.0.0 and proceeded to overwrite the Hello.dll 1.0.0 with the 2.0.0 version. I then launch HelloWorld.exe and it worked fine.

I expected it to crash and burn immediately because the referenced Hello.dll when I compiled the EXE was 1.0.0. Now, the 1.0.0 DLL has been replaced by 2.0.0 but it still worked!

As per MSDN:

By default, an assembly will only use types from the exact same assembly (name and version number) that it was built and tested with. That is, if you have an assembly that uses a type from version 1.0.0.2 of another assembly, it will (by default) not use the same type from version 1.0.0.4 of the other assembly. This use of both name and version to identify referenced assemblies helps avoid the "DLL Hell" problem of upgrades to one application breaking other applications.

Questions:

1. Why did it work?
2. How to make it NOT work?
3. BONUS QUESTION: What happens during the build process? Isn't the version of external dependencies hard coded to the main dependency?

Note that Hello.dll is not strongly named.

Here's the manifest for HelloWorld.exe:

// Metadata version: v2.0.50727
.assembly extern mscorlib
{
  .publickeytoken = (B7 7A 5C 56 19 34 E0 89 )                         // .zV.4..
  .ver 2:0:0:0
}
.assembly extern Hello
{
  .ver 2:0:0:0
}
.assembly HelloWorld
{
...//snipped
}

Here's the Assembly Binding Log taken from Fuslogvw.exe (Assembly Binding Log Viewer):

=== Pre-bind state information ===
LOG: User = ian.uy
LOG: DisplayName = Hello, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null
 (Fully-specified)
LOG: Appbase = file:///C:/Users/ian.uy/Desktop/HelloWorld/HelloWorld/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : HelloWorld, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from C:WindowsMicrosoft.NETFrameworkv2.0.50727configmachine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/Users/ian.uy/Desktop/HelloWorld/HelloWorld/bin/Debug/Hello.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:Usersian.uyDesktopHelloWorldHelloWorldinDebugHello.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: Hello, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
LOG: Binding succeeds. Returns assembly from C:Usersian.uyDesktopHelloWorldHelloWorldinDebugHello.dll.
LOG: Assembly is loaded in default load context.

Answer 1

The runtime distinguishes between regular and strong-named assemblies for the purposes of versioning. Version checking only occurs with strong-named assemblies.

(source: https://docs.microsoft.com/en-us/dotnet/framework/app-domains/assembly-versioning)

Therefor, the answers are as follows:

Why did it work?

Because the assembly isn't strong-named

How to make it NOT work?

Make the assembly strong-named

What happens during the build process?

Depends

• Use specific version = false: compiles against the first file matching the reference in the project, takes any version
• Use specific version = true: compiles against the first file found matching the reference including the specified version in the project

Isn't the version of external dependencies hard coded to the main dependency?

Yes, the versions of referenced assemblies are hard-coded. You can verify this by using a decompiler (e.g. ILSpy) to read this information