it-swarm.com.de

Datei oder Assembly System.Threading.Tasks Version 2.5.19.0 konnte nicht geladen werden

Ich habe ein WPF (.NET 4) -Projekt mit der Google URL-Shortener-API. Ich habe die Client-Bibliothek über Nugget https://www.nuget.org/packages/Google.Apis.Urlshortener.v1/1.7.0.25 installiert -beta

die Anwendung funktioniert gut in Visual Studio, aber sobald sie veröffentlicht wurde, wird die Ausnahme ausgelöst. Datei oder Assembly System.Threading.Tasks, Version = 2.5.19.0 konnte nicht geladen werden. Diese und alle anderen Assemblys sind im Ordner vorhanden Installationsordner, und es wird mit der Anwendung veröffentlicht. Ich habe im Internet gesucht, und die Leute schlagen vor, die Abhängigkeitsbibliotheken in der app.config manuell zu binden. Es funktioniert immer noch nicht, da alle meine Abhängigkeitsbibliotheken bereits in der app.config erwähnt werden. Nachfolgend sehen Sie meine app.config

<runtime>
    <assemblyBinding xmlns="urn:schemas-Microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
        <bindingRedirect oldVersion="0.0.0.0-2.5.19.0" newVersion="2.5.19.0"/>
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Threading.Tasks" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
        <bindingRedirect oldVersion="0.0.0.0-2.5.19.0" newVersion="2.5.19.0"/>
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-2.1.10.0" newVersion="2.1.10.0" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="System.Net.Http.Primitives" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
        <bindingRedirect oldVersion="0.0.0.0-2.1.10.0" newVersion="2.1.10.0"/>
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="log4net" publicKeyToken="669e0ddf0bb1aa2a" culture="neutral"/>
        <bindingRedirect oldVersion="0.0.0.0-1.2.13.0" newVersion="1.2.13.0"/>
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Threading.Tasks.Extensions.Desktop" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
        <bindingRedirect oldVersion="0.0.0.0-1.0.165.0" newVersion="1.0.165.0"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
11
Syed Waqas

Sie können mit dem Microsoft BCL-Teamblog beginnen und die app.config bereinigen, indem Sie die falschen Einträge entfernen.

http://blogs.msdn.com/b/bclteam/p/asynctargetingpackkb.aspx

Ausgabe 6

Symptome

Wenn Sie das NuGet-Paket einem Projekt hinzufügen, das von einem anderen Projekt mit einem anderen Zielframework verwendet wird, werden möglicherweise Warnungen Angezeigt, die der folgenden ähneln:

Der primäre Verweis "Microsoft.Threading.Tasks, Version = 1.0.12.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a, ProcessorArchitecture = MSIL" konnte nicht aufgelöst werden, da es über eine indirekte Abhängigkeit vom Framework Assembly "System.Runtime, Version = 2.5.19.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a" , das im derzeit angesprochenen Framework nicht aufgelöst werden konnte. [.____. .] ".NETFramework, Version = v4.5". Um dieses Problem zu beheben, entfernen Sie entweder Den Verweis "Microsoft.Threading.Tasks, Version = 1.0.12.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a, ProcessorArchitecture = MSIL" oder Richten Sie Ihre Anwendung erneut auf eine Framework-Version aus, die "System.Runtime, Version = 2.5.19.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a" enthält.

Der primäre Verweis "Microsoft.Threading.Tasks.Extensions, Version = 1.0.12.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a, ProcessorArchitecture = MSIL" konnte nicht aufgelöst werden, da es ein indirekte Abhängigkeit vom Framework Assembly "System.Runtime, Version = 2.5.19.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a" , das im aktuell angesprochenen Framework nicht aufgelöst werden konnte. .____.] ".NETFramework, Version = v4.5". Um dieses Problem zu beheben, entfernen Sie entweder Den Verweis "Microsoft.Threading.Tasks.Extensions, Version = 1.0.12.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a, ProcessorArchitecture = MSIL "oder richten Sie Ihre Anwendung auf eine Framework-Version aus, die" System.Runtime, Version = 2.5.19.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a "enthält.

Lösung

Das Problem ist, dass NuGet falsche Bindungsumleitungen für Plattformassemblies hinzugefügt hat. Um sie zu entfernen, öffnen Sie die app.config für Das Projekt, das die Warnungen verursacht hat, und entfernen Sie die hervorgehobenen - Einträge ( StackOverflow unterstützt keine Hervorhebung ):

 <?xmlversion="1.0"encoding="utf-8"?>
   <configuration>   
    <runtime>
     <assemblyBindingxmlns="urn:schemas-Microsoft-com:asm.v1">
       <dependentAssembly>                     
         <assemblyIdentityname="System.Runtime"publicKeyToken="b03f5f7f11d50a3a"culture="neutral" />
         <bindingRedirectoldVersion="0.0.0.0-2.5.19.0" newVersion="2.5.19.0" />
       </dependentAssembly>
       <dependentAssembly>
         <assemblyIdentityname="System.Threading.Tasks"publicKeyToken="b03f5f7f11d50a3a"culture="neutral" />
         <bindingRedirectoldVersion="0.0.0.0-2.5.19.0" newVersion="2.5.19.0" />
       </dependentAssembly>
      </assemblyBinding>
    </runtime>
  </configuration>

Update von Lex Li:

Mit .NET Framework 4.0 am Ende des Lebenszyklus sollten Sie das async-targeting pack selbst überlegen.). Wenn diese Abhängigkeit von einem NuGet-Paket Stammt, sollten Sie auch prüfen, ob Das NuGet-Paket hat eine neuere Version, die keine solche Abhängigkeit hat.

10
Lex Li

Ich hatte in einem UWP-Projekt (VS2015) ein sehr ähnliches Problem ("Datei oder Assembly Microsoft.Threading.Tasks, Version = 1.0.12.0 konnte nicht geladen werden"), und das Problem wurde durch die Installation des Microsoft.Bcl.Async-Pakets behoben aus NuGet

0
Detail

Ich hatte genau das gleiche Problem, wurde jedoch durch die Assembly Microsoft.Rest.ClientRuntime verursacht. In meinem Fall musste ich nur "Copy local = True" für den Verweis auf Microsoft.Rest.ClientRuntime setzen.

0
Björn