Assembly binding change does not work

I am trying to configure assembly binding redirection using the following app.config file:

<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 am running the program on a machine with version 9.0.242.0 in the GAC with the specified public key token. The CLR does not seem to even try to redirect the binding to use this version.

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 to put dll 9.0.242.0 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 redirection to use "9.0.242.0" instead of "9.0.0.0" in app.config, and this did not work, although I do not think it should matter.

From what I understand, the whole point of binding redirection is to use a version that does not match the one with which the program was built. Am I missing something here at all? I am trying to do what I am trying to do, and if so, what is the idea why it is not working?

Cheers, Adam

+29
source share
12 answers

Any typo in the xml configuration could be the cause. The loader just does not see your configuration. I also had an hour of headache until I realized that the error was in the "=" symbol instead of "-" in the schema name:

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

Just carefully check all attribute names and values. I think "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> 
+26
source

Make sure the <configuration> has a namespace attribute . Otherwise, the <assemblyBinding> will be ignored.

Wrong:

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

On right:

 <configuration> 

(from fooobar.com/questions/25420 / ... )

+16
source

I found that assembly binding redirection does not work due to the lack of a namespace in 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

No note: 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> 

+11
source

in my case I had to delete

 appliesTo="v2.0.05727" 

from

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

My problem was resolved when I translated the redirect configuration binding to the machine.config file.

+3
source

I had a similar problem when moving bindredirects to Machine.Config was the only thing that worked. This was not an ideal solution in my winform application, because I am distributing my application to clients.

Decision:

Make sure the .config file is in the directory from which your application is running. for example, if your AppName is "MyApp", then the redirection should be in the file "MyApp.exe.Config" in the application directory.

I had to do this even if the code using third-party DLL files is in different dlls in my solution and adding .dll.config did not help.

+3
source

Eccentric password policies can also ignore assemblyBinding elements in the configuration. Characters such as '&' and '^' are apparently not allowed in the configuration file. The XML tools in Notepad ++ showed this to me after several hours of working with the assembly binding view tool.

+1
source

If you install Visual Studio 2017 without some of the ASP.NET development tools, it will still load the web project, compile and compile it. It will simply issue warnings about versions of the NuGet package because it does not know what to do with the web.config file and therefore cannot see the binding redirects.

Fixing the installation solved my problem, but it took a long time to understand.

Visual Studio Installer screenshot

+1
source

If this helps someone, I came across this because I did not enter the full version for newVersion. that is, I had newVersion="3.0.1" instead of newVersion="3.0.1.0"

0
source

Check if the error Explicit redirection binding on xxx, Culture = neutral, PublicKeyToken = xxx "conflicts with autogenerated binding redirection

will appear in the output window (it will not appear in the error window)

0
source

Thanks so much for the answers, especially 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 that did NOT match the design:

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

dependent collector xmlns = "" was the culprit. As soon as I compared my with your answer and fixed it, it worked. thanks for the help

0
source

Another solution for those struggling too

Make sure that each <dependentAssembly> <assemblyIdentity> has only one <assemblyIdentity> and one <bindingRedirect> . In my scenario, I had two in one, which caused a cascading failure of several 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 binding of SimpleInjector to 4.4.2.0, it was bound to 5.2.3.0, which led to an error saying that it could not correctly bind System.Web.Mvc, hiding the true problem

0
source

Source: https://habr.com/ru/post/1243671/


All Articles