Assembly binding redirect does not work

Question

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

Well, I was going crazy, with a similar issue just now. In my case... I did everything correctly, I just needed to reboot the server. I swear I didn't have to reboot the dev server when I made the change in dev, but on the prod server, I did for some reason. Anyway, once again, when in doubt, try a reboot. :D — neminem, May 25 '23 at 19:28

score 48 · Answer 1 · answered Oct 20 '10 at 19:34

48

Any typo in configuration xml can be a cause. Loader just can't see your configuration. I also had a hour of headache until I realize that the error was in character "=" instead of "-" in schema name:

<assemblyBinding xmlns="urn:schemas=microsoft-com:asm.v1">

Just check carefully all attribute names and values. I guess "PublicKeyToken" should be "publicKeyToken"

This should work:

<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>

answered Oct 20 '10 at 19:34

Shrike

9,218
7
68
105

5

adding `xmlns="urn:schemas=microsoft-com:asm.v1"` solved the problem for me. Thanks! – trailmax Jul 02 '13 at 14:37
36

The wrong one (with an = instead of -) *worked* for you? – Zack Jul 23 '14 at 16:53
1

One common mistake is making bad XML comments. For instance if you add `--` (double-hyphen) *inside* a comment instead of only at the end mark, the entire XML cannot be read. – fernacolo Nov 05 '19 at 20:17
This might be worth noting for the uninitiated, make sure the dependency is in the Assemblies folder – Ricardo Saracino Oct 14 '20 at 13:14
1

please notices that the 'xmlns' tag, must be present on each and every 'assemblyBinding', plus, my case ended with adding assemblyBinding tag between every dependentAssembly – yoni Jan 25 '22 at 12:27

German Latorre · Answer 2 · 2017-08-03T08:37:03.510

36

Make sure your <configuration> tag has no namespace attribute. Otherwise any <assemblyBinding> tag will be ignored.

Wrong:

<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">

Right:

<configuration>

(from https://stackoverflow.com/a/12011221/150370)

edited Aug 03 '17 at 08:37

answered Jun 09 '16 at 09:34

German Latorre

10,058
14
48
59

11

_This_ was the answer. The binding redirects were silently ignored because my `web.config` was so old it had the 2.0 namespace. – Sören Kuklau Oct 16 '18 at 12:36
2

2 hrs of headache and then the solution was as simple as removing ns. – callee.args Jul 09 '21 at 11:34
1

Just spent hours on this issue. After trying my usual assortment, THIS was the answer. Older .NET 2.0 app that was updated to 4+, and the configuration node still had that namespace. Thank you! – Kobold_Warlord Feb 25 '22 at 14:51
Saved my bacon on an auto update to a very old app that broke everything on my day off! – Whelkaholism Mar 02 '23 at 08:52

score 20 · Answer 3 · edited Mar 11 '19 at 22:14

I encountered assembly binding redirect not working, because of a missing namespace on the assemblyBinding element.

Correct

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <dependentAssembly>
    <assemblyIdentity name="TIBCO.Rendezvous" publicKeyToken="1a696d1f90f6158a"/>
    <bindingRedirect oldVersion="1.0.0.0-1.0.3191.28836" newVersion="1.0.3191.28836"/>
  </dependentAssembly>

Incorrect

Note missing: xmlns="urn:schemas-microsoft-com:asm.v1"

<assemblyBinding>
  <dependentAssembly>
    <assemblyIdentity name="TIBCO.Rendezvous" publicKeyToken="1a696d1f90f6158a"/>
    <bindingRedirect oldVersion="1.0.0.0-1.0.3191.28836" newVersion="1.0.3191.28836"/>
  </dependentAssembly>

Would like it noted that the xmlns doesn't seem to be necessary if you are running a website, only a web app - as I started getting this issue after converting from a website to a web app project (e.g. vbproj), and the above fix solved for me. — binderbound, Aug 22 '23 at 02:46

score 10 · Answer 4 · answered Mar 20 '13 at 08:27

10

in my case, i had to remove the

appliesTo="v2.0.05727"

from

<assemblyBinding appliesTo="v2.0.05727" xmlns="urn:schemas-microsoft-com:asm.v1">

answered Mar 20 '13 at 08:27

sawe

1,141
14
24

score 7 · Answer 5 · answered Aug 06 '15 at 14:35

I've had similar issue where moving bindingredirects to Machine.Config was the only thing that worked. That was not ideal solution in my winform app because I distribute my app to clients.

Solution:

Make sure .config file is in the directory where your application is running from. e.g. if your AppName is "MyApp" then Redirects should be in "MyApp.exe.Config" file in application directory.

I had to do this even if the code that uses third party dlls is in different dll in my solution and adding .dll.config didn't help.

Moving bindingredirects to Machine.Config solved my issue. – Ziggler Feb 24 '16 at 22:44 — Ziggler, Feb 24 '16 at 22:44

score 5 · Answer 6 · answered Sep 22 '14 at 06:26

5

My problem was solved when I moved binding redirection configuration to machine.config file.

answered Sep 22 '14 at 06:26

F34R

128
2
5

2

Moving bindingredirects to Machine.Config solved my issue – Ziggler Feb 24 '16 at 22:45
1

Try moving section higher in web.config. Start with right under . Much better than machine.config! – Stan Dec 20 '18 at 20:47

score 5 · Answer 7 · answered Sep 08 '16 at 19:40

5

If it's any help to anybody, I ran into this because I didn't put the full version in for newVersion. i.e., I had newVersion="3.0.1" instead of newVersion="3.0.1.0"

answered Sep 08 '16 at 19:40

JohnnyFun

3,975
2
20
20

score 4 · Answer 8 · answered Jul 15 '19 at 13:02

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

Thanks, that really helped! It seems that due to this problem some or all of redirects were ignored. — Stefan, Mar 06 '21 at 08:16

score 2 · Answer 9 · answered Apr 13 '18 at 15:08

Thank you so much for the answers, especially the one from Shrike. I had one application that worked in development, but not in the deployed version. When I looked more closely, I had this in production, which did NOT match development:

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

dependentAssembly xmlns="" was the culprit. As soon as I compared mine to your answer, and fixed that, it was working. Thanks for the help

score 2 · Answer 10 · edited Mar 27 '19 at 05:43

2

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.

edited Mar 27 '19 at 05:43

JumpingJezza

5,498
11
67
106

answered Oct 25 '18 at 19:25

Bakanekobrain

423
6
14

score 2 · Answer 11 · edited Sep 21 '21 at 13:08

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

The targeted newVersion assembly should be properly located. Use "process monitor" tool from Sysinternals(link) to track how the assembly is searched
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
Pay attention to the name of configuration file that Fusion reads when resolving the targeted assembly.

score 1 · Answer 12 · answered Jun 04 '15 at 08:58

Eccentric password policies can also cause the assemblyBinding items in the config to be ignored. Characters like '&' and '^' are apparently not allowed in a config file. The XML tools in Notepad++ revealed this to me after some hours of fiddling with the Assembly Binding Log Viewer.

score 1 · Answer 13 · answered Jan 21 '20 at 15:25

1

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

answered Jan 21 '20 at 15:25

Selwade

43
5

1

hi and welcome to StackOverflow! Please consider adding some explanation and details to your answer. – hongsy Jan 21 '20 at 15:52
Same here but I wonder why when impersonate is set on IIS authentication for the site dependentAssembly breaks? – drzounds Mar 31 '22 at 20:03

score 1 · Answer 14 · answered Jul 27 '20 at 13:15

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.

score 1 · Answer 15 · answered Oct 08 '21 at 14:46

1

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.

answered Oct 08 '21 at 14:46

raV720

564
3
27

To clarify, for me it was the (appName).exe.config file that needs to be copied alongside the main (appName).exe file. – jtsoftware Dec 10 '21 at 15:12

score 0 · Answer 16 · answered Mar 09 '18 at 13:47

0

Check if the error The explicit binding redirect on xxx , Culture=neutral, PublicKeyToken= xxx" conflicts with an autogenerated binding redirect

appears in the output window (it won't appear in the error window)

answered Mar 09 '18 at 13:47

Markus

1,020
14
18

score 0 · Answer 17 · answered Jan 29 '20 at 11:36

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>

score 0 · Answer 18 · answered May 06 '22 at 09:24

0

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!

answered May 06 '22 at 09:24

Markus

1,020
14
18

score 0 · Answer 19 · answered Jul 14 '23 at 11:14

0

Try removing the publicKeyToken, occasionally they change this between dll versions. This fixed my binding redirect failure for System.Net.Http.dll

answered Jul 14 '23 at 11:14

Markus

1,020
14
18

Assembly binding redirect does not work

19 Answers19

Linked