it-swarm.com.de

Konflikte zwischen System.Net.Http gefunden

Ich habe mehrere Projekte in meiner VS-Lösung. Immer wenn ich ein "System.Net.Http" NuGet-Paket zu einem Paket hinzufüge, wird es als Version 4.2.0.0 angezeigt. Dann mache ich dasselbe und füge dasselbe NuGet-Paket hinzu, jedoch sagt die andere Version. 4.1.1.2

 enter image description here  enter image description here

Dann bekomme ich eine Warnung:

Konflikte zwischen System.Net.Http gefunden

EDIT1:

Gathering dependency information took 1.7 sec
Attempting to resolve dependencies for package 'System.Net.Http.4.3.3' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'System.Net.Http.4.3.3'
Resolved actions to install package 'System.Net.Http.4.3.3'
Retrieving package 'System.Net.Http 4.3.3' from 'nuget.org'.
Adding package 'System.Net.Http.4.3.3' to folder 'C:\...Service\packages'
Added package 'System.Net.Http.4.3.3' to folder 'C:\...Service\packages'
Added package 'System.Net.Http.4.3.3' to 'packages.config'
Successfully installed 'System.Net.Http 4.3.3' to ....Service
Executing nuget actions took 2.05 sec
Time Elapsed: 00:00:03.8937113

Bitte beachten Sie, dass die richtige Version installiert ist. Jedoch => Requisiten => Version sagt 4.1.1.2

 enter image description here

10
ShaneKm

Sie können die Version, die Sie installieren, erzwingen, sodass Sie beide Projekte ausrichten oder im Ausgabefenster eine Meldung finden können, die Ihnen mitteilt, was falsch ist oder welche Abhängigkeiten Sie haben . Seit dem offizieller Link listet kein Release 4.2 auf, ich würde das tun (lösungsweit)

Install-Package System.Net.Http -Version 4.1.1

Oder für beide Projekte

Get-Project ProjectName | Install-Package System.Net.Http -Version 4.1.1

Oder noch besser (mit der letzten Version)

Install-Package System.Net.Http -Version 4.3.3

EDIT

Anscheinend sind Sie nicht die ersten, die dies erfahren . Wie wäre es mit der Antwort hier ? Grundsätzlich können Sie diesen Abschnitt von beiden -Projekt-Konfigurationsdateien ausrichten:

  <runtime>
    <assemblyBinding xmlns="urn:schemas-Microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.1.2" newVersion="4.2.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

Möglicherweise müssen Sie den Tokenwert anpassen. __ Falls Sie die Konfigurationsdatei für beide Projekte einfügen möchten =

3
Francesco B.

Bearbeiten: Dies geschieht nur bei Verwendung von .NET Framework. In .NET Core/Standard land scheint die neueste System.Net.Http Assembly-Version immer 4.1.2.0 zu sein - es ist keine Version 4.2.0.0 verfügbar.

Das Problem in Bezug auf System.Net.Http ist way, way komplizierter als die Antworten hier zu sein scheinen ...

  1. Ja, es gibt ein System.Net.Http-NuGet-Paket, aber nein, es wird not nicht die neueste Version derselben Assembly installieren (es enthält Version 4.1.1.2 der System.Net.Http-Assembly, nicht 4.2.0.0).
  2. Die neueste Version von Microsoft Visual Studio (oder Microsoft Visual Studio Build Tools) enthält Version 4.2.0.0, jedoch bedeutet nicht, dass Ihre .csproj diese immer verwendet ...
  3. Aus irgendeinem Grund (den ich noch nicht verstehen konnte) ist der einzige garantierte Weg zur Verwendung von 4.2.0.0 die Referenz auf bestimmte NuGet-Pakete, die es verwenden, wie beispielsweise System.Buffers (Version 4.5.0).

TL; DR:

Fügen Sie System.Buffers 4.5.0+ NuGet reference zu Ihrem Projekt hinzu, wenn Sie sicherstellen möchten, dass System.Net.Http 4.2.0.0 Assembly verwendet wird.

Verweise:

21
rsenna

Dies geschieht in der Regel, wenn Sie einen Verweis auf das Framework System.Net.Http haben, aber einer Ihrer Paketverweise erfordert das NuGet-Paket System.Net.Http.

Wenn Sie einen Verweis auf diese Assembly haben, entfernen Sie sie und installieren Sie stattdessen das NuGet-Paket

7
erikkallen

Nachdem ich alle hier vorgestellten Lösungen und die in diese Antwort zitierten Referenzen durchgegangen war, habe ich dies schließlich vollständig gelöst. Ich glaube, dass jeder, der dieses Problem hat, etwas tun sollte:

  1. Aktualisieren Sie alle NuGet-Pakete auf den neuesten Stand.
  2. Migrieren Sie NuGet von packages.config nach PackageReference gemäß den Anweisungen hier . Klicken Sie im Projektmappen-Explorer im Prinzip mit der rechten Maustaste auf den Knoten References oder die Datei packages.config, und wählen Sie Packages.config nach PackageReference ... migrieren aus. ASP.NET-Websiteprojekte müssen packages.config verwenden.
  3. Entfernen Sie alle Verweise auf System.Net.Http, die nicht von NuGet verwaltet werden (für Projekte, die PackageReference verwenden), sollte das NuGet-Symbol enter image description here neben der Referenz im Projektmappen-Explorer). Ersetzen Sie die entfernten System.Net.Http-Referenzen durch das entsprechende NuGet-Paket, wenn Sie sicher sind, dass für Ihr Projekt System.Net.Http erforderlich ist (versuchen Sie es zuerst ohne zu bauen). Achten Sie bei Projekten, die packages.config verwenden, besonders darauf, dass Verweise auf System.Net.Http erforderlich sind und auch NuGet verwendet wird. Es kann hilfreich sein, System.Net.Http trotzdem über NuGet zu entfernen und erneut hinzuzufügen (für alle -Projekte, die darauf verweisen), auch wenn bereits mit NuGet darauf verwiesen wurde. Ich habe festgestellt, dass Schritt 2 irgendwo eine Trennung verursachen kann.
  4. Aktualisieren Sie auf .NET Framework 4.7.2 aus den angegebenen Gründen hier . Sie können es von hier herunterladen oder das Visual Studio-Installationsprogramm für VS 2017 verwenden.
  5. Entfernen Sie all die Assembly-Bindungen aus allen app.config - und Web.config -Dateien, und erstellen Sie dann Ihre Lösung. app.config Bindungen sind nicht mehr erforderlich. Web.config Bindungen werden im nächsten Schritt erneut hinzugefügt. Wenn Sie sie jedoch zuerst entfernen, wird sichergestellt, dass in den Bindungen keine veralteten Versionen vorhanden sind.
  6. In dieser Phase können jetzt andere Konflikte auftreten. Fügen Sie für Ihre ASP.NET-Website-Projekte die Bindungsumleitungen zu Ihrer Web.config hinzu, die Sie in den Warnungen erhalten. Fügen Sie für andere .NET Framework-Anwendungen für die Referenzen, für die Sie Warnungen erhalten, die entsprechenden NuGet-Pakete in den Projekten hinzu, in denen Sie die Warnungen erhalten, auch wenn das Projekt ohne Hinzufügen der Referenz kompiliert wird. Dies zwingt das Projekt zur Verwendung der NuGet-Version und nicht der lokalen .NET Framework-Version, auf die möglicherweise von einem anderen Paket verwiesen wird. Dies ist auf den Crossover zwischen .NET Framework und .NET Standard zurückzuführen, wie er in rsennas vorgenannte Antwort erwähnt wird. Nach dem Erstellen müssen Sie diesen Schritt möglicherweise für weitere Verweise wiederholen.

Wenn Sie später feststellen, dass Sie aufgrund von offensichtlichen Inkongruenzen nach dem Hinzufügen einer Referenz zu Laufzeitausnahmen kommen (sogar während des Komponententests), entfernen Sie alle verbindlichen Weiterleitungen aus dem betreffenden Website-Projekt. Fügen Sie dann die in der Warnung vorgeschlagenen Empfehlungen erneut als hinzu pro Schritt 6.

Ich habe viel Zeit damit verbracht, dieses Problem methodisch zu lösen, daher glaube ich, dass die oben genannten Schritte die Probleme der meisten Menschen vollständig lösen würden, auch wenn in ungewöhnlichen Fällen etwas Querdenken erforderlich ist. Lassen Sie mich wissen, ob dies für Sie funktioniert (oder nicht funktioniert).

6
Neo

Die 6 Schritte, die Neo oben gepostet hat, haben mir geholfen, meine ASP.NET-Paketprobleme zu lösen! Vielen Dank Neo! Ich habe mich über eine Woche damit beschäftigt.

Ich möchte nur meine persönlichen Notizen aus meiner Erfahrung mit der Implementierung von Neos Post weitergeben.

Ich hatte ein ASP.NET-Web-API-Projekt, das auf .NET Framework 4.6.1 abzielte.

Folgendes habe ich getan:

  • Aktualisieren Sie auf .Net Framework 4.7.2
  • Aktualisieren Sie alle NuGet-Pakete auf den neuesten Stand.
  • (optional kann auch "update-package -reinstall" ausgeführt werden, um sicherzustellen, dass alle Pakete 4.7.2 zugeordnet sind
  • Pakete konsolidieren
  • Ich bin nicht von packages.config nach PackageRefence migriert, da dies in ASP.NET nicht möglich ist
  • Verweise von System.Net.Http und anderen, die dies benötigten, wurden entfernt und als NuGet-Pakete hinzugefügt.
  • Alle Assemblybindungen aus web.config und app.config entfernt (in den Bibliotheken .Core, .Tests, .IntegrationTests)
  • Bindungsweiterleitungen für unsere hauseigenen NuGet-Pakete hinzugefügt, deren Versionsnummern mit Text endeten (n.n.n.n-beta), deren Text jedoch entfernt wurde und die nur Nummern enthielten (n.n.n.n)
  • Dies wurde allen .csproj-Dateien hinzugefügt:
 <PropertyGroup> 
 <AutoUnifyAssemblyReferences> true </ AutoUnifyAssemblyReferences> 
 </ PropertyGroup> 
  • Stellen Sie sicher, dass die Pakete in allen packages.config-Dateien in allen Projekten in der Lösung Die gleichen Versionen haben.
    • Stellen Sie sicher, dass die Versionen in der web.config identisch sind
    • Stellen Sie sicher, dass die Versionen in der .csproj-Datei identisch sind, falls zutreffend
  • Verwenden Sie Microsoft.Net.Compilers 3.1.1 (aktualisieren Sie alle .csproj-Dateien in der Projektmappe, einschließlich .Tests und .IntegrationTests).
  • Für Data Protection API (DPAPI), die Redis verwenden:
    • Installieren Sie Microsoft.AspNetCore.DataProtection.StackExchangeRedis 2.2.5
    • StackExchange.Redis 2.0.601
    • Aktualisieren Sie System.Numerics.Vectors auf 4.4.0 (Hinweis: 4.5.0 enthält einen Fehler, der die Serververbindung verhindert).
1
Gary

Es gibt eine neue Lösung, die ab dem 9. Oktober 2018 funktioniert. 

  1. Sie müssen alle Ihre Verweise auf System.Net.Http auf die neueste Version 4.3.4 aktualisieren. 
  2. Sie sollten das Paket in Ihrer .Net Framework-Lösung installieren, die den Konflikt verursacht, auch wenn das Paket nicht explizit erforderlich ist.
  3. Wenn Ihr Projekt über die neue Projektstruktur verfügt, bearbeiten Sie es und stellen Sie sicher, dass es die folgende Paketreferenz enthält:

    <PackageReference Include="System.Net.Http" Version="4.3.4" />
    
  4. Durchsuchen Sie Ihre Lösung und löschen Sie alle vorhandenen verbindlichen Weiterleitungen für System.Net.Http, die wie folgt aussehen

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

  5. Rebuild: Die Warnung sollte jetzt weg sein und der Code sollte ordnungsgemäß erstellt und ausgeführt werden

0
ObiEff