1

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.
disruptive
  • 5,687
  • 15
  • 71
  • 135
  • See if http://stackoverflow.com/questions/215026/the-located-assemblys-manifest-definition-does-not-match-the-assembly-reference?rq=1 helps. – Moo-Juice Nov 06 '13 at 11:36
  • 4
    It is hard to tell with all the redacted parts; which bits were different? which bits were the same? In particular, are Version, Culture and PublicKeyToken identical (**identical**, not similar) in both? Have you tried a binding redirect? (i.e. ``) – Marc Gravell Nov 06 '13 at 11:38
  • Sorry for the redacting. – disruptive Nov 06 '13 at 11:43
  • @MarcGravell How do I check the Public keys? The old dll was part of the solution and was referenced that way. How do I go about checking the tokens on this? – disruptive Nov 06 '13 at 12:25
  • 2
    Try logging Fusion activities. Scott Hanselman has a blog about this topic http://www.hanselman.com/blog/BackToBasicsUsingFusionLogViewerToDebugObscureLoaderErrors.aspx – Frode Nov 06 '13 at 12:32
  • @user673600 `I'd just look at the files in reflector or any similar tool; heck, the exception message might print both – Marc Gravell Nov 06 '13 at 12:39
  • Does the patch have the same target framework as the project? I think one cause of this problem is, eg. DLL targets .NET 4 but project targets .NET 4 Client Profile. – groverboy Nov 06 '13 at 12:50
  • @groverboy - is there anyway to checl what version of .NET the dll is compiled against? – disruptive Nov 06 '13 at 14:55

1 Answers1

11

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

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536