Ich programmiere eine Klassenbibliothek (namens mylibrary.dll), die selbst auf einige weitere Bibliotheken verweist -> verwendet die folgenden DLLs (von package.config für Versionsübersicht genommen):Datei oder Baugruppe konnte nicht geladen werden Newtonsoft.Json, Version = 6.0.0.0 in Kombination mit Microsoft.AspNet.WebApi.Client
<package id="EntityFramework" version="6.0.0" targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi.Client" version="5.2.3" targetFramework="net45" />
<package id="Newtonsoft.Json" version="8.0.2" targetFramework="net45" />
<package id="System.Data.SQLite" version="1.0.99.0" targetFramework="net45" />
<package id="System.Data.SQLite.Core" version="1.0.99.0" targetFramework="net45" />
<package id="System.Data.SQLite.EF6" version="1.0.99.0" targetFramework="net45" />
<package id="System.Data.SQLite.Linq" version="1.0.99.0" targetFramework="net45" />
<package id="UnmanagedExports" version="1.2.7" targetFramework="net45" />`
MyLibrary.dll ist ein Wrapper, der einige verwalteten Code zu einem Anrufer aussetzt, die nicht verwalteten Code erwartet (in anderen Worten, wo nativen DLL Einträge erwartet).
Wenn ich die öffentliche Schnittstelle von Mylibrary.dll über NUnit Testmethoden testen, gibt es überhaupt keinen Fehler. Aber wenn ich dieselben Methoden über die gleiche Schnittstelle vom targetapplication.exe nenne ich die folgenden Situationen erkennen:
- Testmethode A: Ruft eine einfache JSON-String-Operation (Verwendung von Newtonsoft.JSON Bibliothek macht) und laufen Alles gut.
- Testmethode B: Ruft eine Methode, die eine PostAsync tut und weiterhin
var vResponseObject = await vResponse.Content.ReadAsAsync<ApiResponse<T>>().ConfigureAwait(false);
Hinter den Kulissen der ReadAsAsync Aufruf Newtonsoft.JSON das Objekt vom Typ <T>
deserialisieren verwendet. Es scheint, dass diese Funktion derjenige ist, der den Fehler erzeugt:
Could not load file or assembly 'Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=...........' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
HTTPContent.ReadAsAsync durch Microsoft.AspNet.WebApi.Client vorgesehen (erweitert System.Net.Http), die sich auf Newtonsoft.JSON Version hängt 6.0 .x (siehe NuGet-Abhängigkeit für dieses Paket). Version 6.0.x ist nicht installiert, stattdessen Version 8.0.x. So gibt es einen Bedarf für assebly Bindungs Umleitung, die in app.config verwaltet:
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" />
</dependentAssembly>
</assemblyBinding>
Nun weiß ich nicht, wie das zu lösen. In meinem Projekt ist Microsoft.AspNet.WebApi.Client die einzige der anderen Bibliotheken, die auf Newtonsoft.JSON verweist (Version 6.0.x, die gleiche Version, die der Fehler mir erzählt). Es scheint, dass die Bindungsumleitung einfach ignoriert wird. Weil es keine "Datei nicht gefunden Ausnahme" ist Ich denke, es ist in der Lage, Version 8 der DLL zu finden, aber 6 erwartet, oder? Alle DLLs im selben Verzeichnis wie die targetapplication.exe
aktualisiert mit einer Teillösung: Als Abhilfe konnte ich den externen Anruf von Newtonsoft.Json durch System.Net.Http.Formatting vermeiden. dll
//vResponseObject = await vResponse.Content.ReadAsAsync<ApiResponse<T>>().ConfigureAwait(false);
string vStr = await vResponse.Content.ReadAsStringAsync();
vResponseObject = JsonConvert.DeserializeObject<ApiResponse<T>>(vStr);
Aber das ist wirklich keine gültige Lösung für die weitere Entwicklung, wenn ich um eine Anrufe wie mydll zu codieren haben -> thirdparty.dll -> anotherthirdparty.dll
Entspricht das PublicKeyToken für Newtonsoft.Json in der Fehlermeldung was in Ihrer app.config? –
Hallo, danke für den Hinweis aber ja, das publicKeyToken in der Fehlermeldung ist das gleiche wie in der AssemblyIdentity Tag. –
Haben Sie alle Vorschläge unter https://stackoverflow.com/questions/3490327/assembly-binding-redirect-does-not-work getestet? – danio