wake-up-neo.com

Umleitung der Assemblybindung funktioniert nicht

Ich versuche, eine Assembly-Bindungsumleitung mithilfe der folgenden app.config einzurichten:

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

Ich führe das Programm auf einem Computer mit der Version 9.0.242.0 im GAC mit dem angegebenen öffentlichen Schlüsseltoken aus. Die CLR scheint jedoch nicht einmal zu versuchen, die Bindung umzuleiten, um diese Version zu verwenden.

Folgendes bekomme ich 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.

Wenn ich versucht habe, die DLL der Version 9.0.242.0 in den Prüfpfad zu setzen, erhalte ich stattdessen Folgendes:

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.

Beachten Sie, dass ich auch versucht habe, die Weiterleitung so zu ändern, dass in der app.config "9.0.242.0" anstelle von "9.0.0.0" verwendet wird. Das hat nicht funktioniert, obwohl ich glaube, dass dies keinen Unterschied machen sollte.

Nach allem, was ich verstehe, ist das Umleiten einer Bindung eine Version, die nicht zu der passt, mit der das Programm erstellt wurde. Fehlt mir hier etwas? Ist das, was ich versuche zu tun, und wenn ja, eine Idee, warum es nicht funktioniert?

Prost, Adam

26
Adam

Jeder Tippfehler in der Konfigurations-XML kann eine Ursache sein. Der Loader kann Ihre Konfiguration nur nicht sehen .. Ich hatte auch eine Stunde Kopfschmerzen, bis mir klar wurde, dass der Fehler im Zeichen "=" statt "-" im Schemanamen war:

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

Überprüfen Sie sorgfältig alle Attributnamen und -werte. Ich denke, "PublicKeyToken" sollte "publicKeyToken" sein.

Das sollte funktionieren:

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

Stellen Sie sicher, dass Ihr <configuration>-Tag ein no Namespace-Attribut hat. Andernfalls wird jedes <assemblyBinding>-Tag ignoriert.

Falsch:

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

Recht:

<configuration>

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

12
German Latorre

Ich habe festgestellt, dass die Bindungsumleitung aufgrund eines fehlenden Namespaces im Element assemblyBinding funktioniert.

Richtig

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

Falsch

Hinweis fehlt: 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>

10
Edward Wilde

in meinem fall musste ich das entfernen 

appliesTo="v2.0.05727" 

von

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

Ich hatte ein ähnliches Problem, bei dem das Verschieben von Bindungsverweisen auf Machine.Config das einzige war, das funktionierte. Das war keine ideale Lösung in meiner Winform-App, da ich meine App an Kunden verteile.

Lösung:

Stellen Sie sicher, dass sich die .config-Datei in dem Verzeichnis befindet, in dem Ihre Anwendung ausgeführt wird. z.B. Wenn Ihr AppName "MyApp" ist, sollten Weiterleitungen in "MyApp.exe.Config" im Anwendungsverzeichnis enthalten sein. 

Ich musste dies auch tun, wenn der Code, der Drittanbieter-DLLs verwendet, in einer anderen DLL in meiner Projektmappe enthalten ist. 

3
Patel

Mein Problem wurde behoben, als ich die Bindungsumleitungskonfiguration in die Datei machine.config verschoben habe.

3
F34R

Exzentrische Kennwortrichtlinien können auch dazu führen, dass die assemblyBinding-Elemente in der Konfiguration ignoriert werden. Zeichen wie '&' und '^' sind in einer Konfigurationsdatei anscheinend nicht erlaubt. Die XML-Tools in Notepad ++ haben mir dies gezeigt, nachdem ich einige Stunden mit dem Assembly Binding Log Viewer gespielt hatte.

1
jscheppers

Wenn es jemandem geholfen hat, bin ich darauf gestoßen, weil ich nicht die Vollversion für newVersion eingebaut habe. Ich hatte newVersion="3.0.1" anstelle von newVersion="3.0.1.0"

0
JohnnyFun

Wenn Sie Visual Studio 2017 ohne den Teil der ASP.NET-Entwicklungstools installieren, wird weiterhin ein Webprojekt geladen, kompiliert und erstellt. Es werden lediglich Warnungen zu den NuGet-Paketversionen ausgegeben, da sie nicht wissen, was mit der Datei web.config zu tun ist, und daher keine Bindungsumleitungen sehen können. 

Durch das Reparieren der Installation wurde mein Problem behoben, aber es dauerte ewig, bis es herausgefunden wurde.

0
Bakanekobrain

Vielen Dank für die Antworten, besonders die von Shrike. Ich hatte eine Anwendung, die in der Entwicklung funktionierte, aber nicht in der bereitgestellten Version. Wenn ich genauer hinschaute, hatte ich dies in der Produktion, was NICHT der Entwicklung entsprach:

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

dependAssembly xmlns = "" war der Schuldige. Sobald ich meine mit Ihrer Antwort verglich und korrigiert hatte, funktionierte es. Danke für die Hilfe

0
Wayne

Prüfen Sie, ob der Fehler Die explizite Bindungsumleitung auf xxx, Culture = neutral, PublicKeyToken = xxx "mit einer automatisch generierten Bindungsumleitung kollidiert

erscheint im Ausgabefenster (wird nicht im Fehlerfenster angezeigt)

0
Markus

Eine zusätzliche Lösung für diejenigen, die auch Probleme haben

Stellen Sie sicher, dass jeder <dependentAssembly> hat nur einen <assemblyIdentity> und ein <bindingRedirect>. In meinem Szenario hatte ich zwei in einem, was zu einem Kaskadenfehler mehrerer Bindungsumleitungen führte

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

Dies bedeutete, dass anstelle der Bindung von SimpleInjector an 4.4.2.0 eine Bindung an 5.2.3.0 stattfand, was zu dem Fehler führte, dass System.Web.Mvc nicht ordnungsgemäß gebunden werden konnte, wodurch das wahre Problem maskiert wurde

0