-1

There are quite a few SO questions about binding-redirects but none that explain why the assembly loader might fail to match a revision for a dll that looks like it clearly should match.

My project is failing at runtime with "Could not load file or assembly". The FusionLog property of the inner exception reads:

=== Pre-bind state information ===
LOG: DisplayName = Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
 (Fully-specified)
LOG: Appbase = file:///D:/work/code/b6/Backend/CSharp/Applications/Web/Ingestion/Backend/csx/Debug/roles/WorkerRole1/approot
LOG: Initial PrivatePath = D:\work\code\b6\Backend\CSharp\Applications\Web\Ingestion\Backend\csx\Debug\roles\WorkerRole1\approot
Calling assembly : Microsoft.Azure.Cosmos.Table, Version=1.0.8.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: D:\work\code\b6\Backend\CSharp\Applications\Web\Ingestion\Backend\csx\Debug\roles\WorkerRole1\approot\WorkerRole1.dll.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Redirect found in application configuration file: 10.0.0.0 redirected to 11.0.1.21818.
LOG: Post-policy reference: Newtonsoft.Json, Version=11.0.1.21818, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
LOG: Attempting download of new URL file:///D:/work/code/b6/Backend/CSharp/Applications/Web/Ingestion/Backend/csx/Debug/roles/WorkerRole1/approot/Newtonsoft.Json.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

These lines

LOG: Redirect found in application configuration file: 10.0.0.0 redirected to 11.0.1.21818
...
file:///D:/work/code/b6/Backend/CSharp/Applications/Web/Ingestion/Backend/csx/Debug/roles/WorkerRole1/approot/Newtonsoft.Json.DLL

indicate that the binding I have set is being applied and that the loader is examining the expected dll.

Looking at the dll properties (from that path) I see that the version matches the redirection... enter image description here

but I'm still getting this mismatch

WRN: Comparing the assembly name resulted in the mismatch: Revision Number

I've also verified the PublicKeyToken is as expected using the sn tool.

Can anyone suggest what might be going on here? All I can think of is that the FusionLog output is incorrect/incomplete and a different dll is actually being examined.

NeilMacMullen
  • 3,339
  • 2
  • 20
  • 22

1 Answers1

1

Not sure what you did to bindredirect under app.config file. I think you have missed assembly version, file version and product version.

BindRedirect uses assembly version rather than what you shown product version and file version. See this document.

Product Version and File Version are used to the external release of the product is used to display the characteristics of the product and is only an external description.

However, Assembly Version is used for specific internal purposes, such as dll parsing, referencing, loading, and binding, then we use the assembly version. And note that the version number cannot be accessed externally, and we can only see it when, for example, vs ide parsing.

In your issue, Newtonsoft.Json 11.0.1 nuget package,

its dll's File Version is 11.0.1.21818, Product Version is 11.0.1, Assembly Version is 11.0.0.0.

So you should check under csproj file and change to use Assembly Version:

 <Reference Include="Newtonsoft.Json, Version=11.0.0.0, Culture=neutral, PublicKeyToken=xxx, processorArchitecture=MSIL">
      <HintPath>..\packages\Newtonsoft.Json.11.0.1\lib\net45\Newtonsoft.Json.dll</HintPath>
 </Reference>

If you used bindredirect under app.config file, use this:

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      ........
      <dependentAssembly>
        <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="xxx" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-11.0.0.0" newVersion="11.0.0.0" />
      </dependentAssembly>

    </assemblyBinding>
  </runtime>
Sara Liu - MSFT
  • 6,007
  • 1
  • 21
  • 27
  • 1
    Thanks Sara - my mistake was in thinking that the FileVersion displayed in the properties dialog was the same as the AssemblyVersion. As described at https://stackoverflow.com/questions/29772065/how-to-check-the-version-of-an-assembly-dll you need to use ildasm to get the AssemblyVersion. For background (and a bonus question!) see https://stackoverflow.com/questions/67200048/what-might-be-causing-apparent-nuget-package-self-references - basically VS is failing to calculate dependencies correctly so I'm trying to fix it by hand :-( – NeilMacMullen Apr 22 '21 at 08:31