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
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>
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>
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>
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">
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.
My problem was solved when I moved binding redirection configuration to machine.config file.
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"
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
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
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.
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.
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)
I had identity impersonate set to true, changed it to false and worked for me
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'm trying to provide a checklist along with tools to solve the problem.
newVerion
assembly should be properly located. Use "process monitor" tool from Sysinternals(link) to track how the assembly is searchedFusion
(assembly loader for .NET Framework) by following steps in this post, then examine the file that has the name of target assemblyFusion
reads when resolving the targeted assembly.User contributions licensed under CC BY-SA 3.0