2016-02-23 2 views
5

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

+0

Entspricht das PublicKeyToken für Newtonsoft.Json in der Fehlermeldung was in Ihrer app.config? –

+0

Hallo, danke für den Hinweis aber ja, das publicKeyToken in der Fehlermeldung ist das gleiche wie in der AssemblyIdentity Tag. –

+0

Haben Sie alle Vorschläge unter https://stackoverflow.com/questions/3490327/assembly-binding-redirect-does-not-work getestet? – danio

Antwort

0

ändern

<bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" /> 

für

<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" /> 

Und in Ihrer Abhängigkeiten Newtonsoft.Json überprüfen. Wenn es das gelbe Symbol hat, löschen Sie es und fügen Sie es manuell hinzu. (Stellen Sie sicher, dass Sie die Version 6.0 hinzufügen). (Sie sollten die DLL in Ihrem Projektordner oder einem anderen Projekt haben). Wenn das nicht funktioniert, füge die alte Version über NuGet hinzu (ich bevorzuge es, sie manuell hinzuzufügen).

Der Speicherort der DLL ist normalerweise: C: \ Benutzer \ Benutzername \ Dokumente \ Visual Studio 2013 \ Projekte \ ProjectFolder \ packages \ Newtonsoft.Json.6.0.8 \ lib \ net45 (oder welche Version von .net)

+0

Hallo, die Referenz funktioniert, kein gelbes Symbol dort. Version 6 ist nicht möglich, es muss> = 8 sein –

0

Ich habe gerade dieses Problem mit Newtonsoft mit Version 7.0.1 gelöst. Ich ersetzen die alte Bindung in meiner web.config-Datei, die seltsam war:

<dependentAssembly> 
    <assemblyIdentity name="Newtonsoft.Json" culture="neutral" publicKeyToken="30ad4fe6b2a6aeed" /> 
    <bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="4.5.0.0" /> 
</dependentAssembly> 

An:

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

schließlich die Newtonsoft Referenz ändern von was auch immer es zeigt auf, auf die Version in Ihrem NuGet-Paket, v8. Sie verweisen höchstwahrscheinlich auf eine von vielen Newton.Json-DLLs, d. H. C: \ Programme (x86) \ Microsoft ASP.NET \ ASP.NET Web Stack 5 \ Packages \ Newtonsoft.Json.6.0.3 \ lib \ net40. Ich habe keine Ahnung, warum es das tut, aber ich hatte nur Probleme mit dieser Bibliothek.

+0

Hallo, wie in meinem ursprünglichen Beitrag erwähnt, sieht der Assembly-Bindungsabschnitt genauso aus wie Ihr verbesserter. Und der Verweis von Newtonsoft.Json verweist auf \ packages \ Newtonsoft.Json.8.0.2 \ lib \ net45 \ Newtonsoft.Json.dll, wobei die lokale Kopie auf true festgelegt ist. Ich frage mich, warum das Test-Routing sehr gut funktioniert und die produktive Anwendung fehlschlägt (derselbe Computer und ich haben die Bibliotheken aus dem Build-Ordner, in dem während der Tests kein Fehler auftritt, in den produktiven Ordner kopiert, in dem der Fehler auftritt ...). –

+0

@ stev-e, wo Sie es lösen können? Wenn das so ist, wie? Danke. –

Verwandte Themen