CODEWITHSUNDEEP
c#visual-studio-2012dll
disruptive
disruptive

Reputation: 5946

The located assembly's manifest definition does not match the assembly reference C# Dll hell

I'm in dll hell here with a large project. I have a dll patch which I'm trying to put into the assembly such that I can overide the built dlls in the project. I'm adding the .dll to the StartProject and replacing the existing one, but I get the following error and I don't know why this is the case. I've tried changing the specific version to False and the runtime versions all look identical for each of the dll's. The only difference in properties between this dll and the others is the use of an option called SpecificVersion - but this is set to false anyway.

Failed processing: System.IO.FileLoadException: Could not load file or assembly
XXX.XXX.XXX, Version=X.X.X.X, Culture=neutral, PublicKeyTok
en=5353c9f66d4ed1ec' or one of its dependencies. The located assembly's manifest
 definition does not match the assembly reference. (Exception from HRESULT: 0x80
131040)
File name: 'XXX.XXX.XXX, Version=X.X.X.X, Culture=neutral, P
ublicKeyToken=xxxxxxxxxxxxxxx'
   at XXX.XXX.XXX.XXX.XXX.XX(.....)

I'm looking at the fuslogvw failure output for binding and I get the following. Sorry for Redacting again.

=== Pre-bind state information ===
LOG: User = X
LOG: DisplayName = DataObjects, Version=0.4.1060.0, Culture=neutral, PublicKeyToken=5353c9f66d4ed1ec
 (Fully-specified)
LOG: Appbase = file://X/lib/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = Program.exe
Calling assembly : Storage, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: Config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Post-policy reference: DataObjects, Version=0.4.1060.0, Culture=neutral, PublicKeyToken=5353c9f66d4ed1ec
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///X/DataObjects.DLL.
LOG: Assembly download was successful. Attempting setup of file: X\DataObjects.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: DataObjects, Version=1.0.0.0, Culture=neutral, PublicKeyToken=5353c9f66d4ed1ec
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: The assembly reference did not match the assembly definition found.
ERR: Run-from-source setup phase failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

Upvotes: 1

Views: 20498

Answers (1)

Hans Passant
Hans Passant

Reputation: 942178

SpecificVersion only matters when you build your project. At runtime, the CLR insists on finding an exact match. In other words, the [AssemblyVersion] of the reference assembly that was used when the project was originally built must be an exact match with the [AssemblyVersion] it finds back at runtime. A mismatch is very dangerous, causing true DLL Hell when the program tries to execute code in the assembly that substantially changed from the code it was tested against.

So if you create a patch then you must be sure that the [AssemblyVersion] attribute as declared in the AssemblyInfo.cs source code file matches the original. Do make sure that you don't let it increment automatically, using [1.0.*] is pretty popular and will always cause this runtime error.

Your assembly is also strong-named, the PublicKeyToken value must match as well. Be sure to sign it with the same private key.

Using a <bindingRedirect> element in the app.exe.config file is a way to force the CLR to accept a version mismatch.

After edit: yes, there's clearly a gross mismatch in the assembly version. The app was built with DataObjects version 0.4.1060.0 but found version 1.0.0.0

Upvotes: 11

Related Questions