Assembly binding redirect does not work

Viewed 64385

I'm trying to set up an assembly binding redirect, using the following app.config:

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.AnalysisServices"
                          PublicKeyToken="89845dcd8080cc91" />
        <bindingRedirect oldVersion="10.0.0.0"
                         newVersion="9.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

I'm running the program on a machine with version 9.0.242.0 in the GAC, with the specified public key token. The CLR doesn't seem to be even trying to redirect the binding to use that version though.

Here is what I get in fuslogvw.exe:

LOG: This bind starts in default load context. LOG: Using application configuration file: \Debug\AssemblyRedirectPOC.exe.Config LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v2.0.50727\config\machine.config. LOG: Post-policy reference: Microsoft.AnalysisServices, Version=10.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91 LOG: GAC Lookup was unsuccessful. LOG: Attempting download of new URL /Debug/Microsoft.AnalysisServices.DLL. LOG: Attempting download of new URL /Debug/Microsoft.AnalysisServices/Microsoft.AnalysisServices.DLL. LOG: Attempting download of new URL /Debug/Microsoft.AnalysisServices.EXE. LOG: Attempting download of new URL /Debug/Microsoft.AnalysisServices/Microsoft.AnalysisServices.EXE. LOG: All probing URLs attempted and failed.

When I tried putting the 9.0.242.0 version dll in the probe path, I get this instead:

LOG: Assembly download was successful. Attempting setup of file: \Debug\Microsoft.AnalysisServices.dll LOG: Entering run-from-source setup phase. LOG: Assembly Name is: Microsoft.AnalysisServices, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91 WRN: Comparing the assembly name resulted in the mismatch: Major Version ERR: The assembly reference did not match the assembly definition found. ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

Note that I also tried changing the redirect to use "9.0.242.0" instead of "9.0.0.0" in the app.config and that didn't work, although I don't think it should make any difference.

From what I understand the whole point of redirecting a binding is to use a version that does not match that which the program was built with. Am I completely missing something here? Is what I'm trying to do possible, and if so, any idea of why it's not working?

Cheers, Adam

18 Answers

One additional solution for those that are also struggling

Ensure that each <dependentAssembly> only has one <assemblyIdentity> and one <bindingRedirect>. In my scenario, I had two in one, which was causing a cascading failure of multiple binding redirects

<dependentAssembly>
        <assemblyIdentity name="System.Net.Http.Formatting" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-5.2.3.0" newVersion="5.2.3.0" />

        <assemblyIdentity name="SimpleInjector" publicKeyToken="984cb50dea722e99" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.4.2.0" newVersion="4.4.2.0" />
</dependentAssembly>

This meant that instead of my SimpleInjector binding to 4.4.2.0 it was binding to 5.2.3.0 which resulted in the error telling me it couldn't bind System.Web.Mvc properly, masking the true issue

If you install Visual Studio 2017 without the ASP.NET development tools part, it will still load a web project and compile and build it. It will just give warnings about the NuGet package versions because it doesn't know what to do with the web.config file and therefore can't see the binding redirects.

Fixing the install fixed my problem but it took forever to figure out.

Visual Studio Installer screenshot

I had identity impersonate set to true, changed it to false and worked for me

I'm trying to provide a checklist along with tools to solve the problem.

  1. The targeted newVersion assembly should be properly located. Use "process monitor" tool from Sysinternals(link) to track how the assembly is searched
  2. Check how the version of targeted assembly is resolved. Enable the log output of Fusion (assembly loader for .NET Framework) by following steps in this post, then examine the file that has the name of target assembly
  3. Pay attention to the name of configuration file that Fusion reads when resolving the targeted assembly.

In my case the app.config file were not copied to destination directory by post-build script. I have created exception for the configuration file in order not to override configuration in destination - and I have totally forgotten about it. So application in destination directory was using old app.config file.

Well, in my case I had the dependentAssembly node outside of the assemblyBinding node. Bad copy pasting.

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="EntityFramework" publicKeyToken="b77a5c561934e089" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>    
    <dependentAssembly>
      <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
      <bindingRedirect oldVersion="0.0.0.0-10.0.0.0" newVersion="10.0.0.0" />
    </dependentAssembly>

  </runtime>

Even if culture="neutral" (or whatever its value is in your case) doesn't appear in some answers here and somewhere else too, in my case it was paramount: when I added it, everything worked out well.

The poster never said what his problem was, so try this too.

I had the same assembly listed twice, once from a couple of years earlier redirecting to an older version. Only one mention of the assembly allowed!

Related