Seltsames Problem mit System.Net.Http 4.2.0.0 nicht gefunden

Ich habe ein seltsames Problem, das mich verrückt macht ...

Ich habe ein einfaches Klassenbibliotheksprojekt (Full .NET Framework, 4.6.1) mit einer Wrapper-Klasse für Funktionen rund um Cosmos DB. Daher habe ich diesem Projekt das NuGet-Paket 1.19.1 „Microsoft.Azure.DocumentDB“ hinzugefügt. Ansonsten verweise ich auf das NuGet-Paket 10.0.3 „Newtonsoft.Json“ sowie auf einige NuGet-Pakete „Microsoft.Diagnostics.EventFlow. *“.

Bisher wird alles fehlerfrei kompiliert.

Sobald ich jedoch meine Wrapper-Klasse erreicht habe, die von einem einfachen Service Fabric Stateless Service (Full .NET Framework 4.6.1) verwendet wird, versuche ich, die folgende Codezeile auszuführen:

_docClient = new DocumentClient(new Uri(cosmosDbEndpointUrl), cosmosDbAuthKey);

Ich bekomme diesen seltsamen Fehler zur Laufzeit:

System.IO.FileNotFoundException aufgetreten HResult = 0x80070002
Message = Datei oder Assembly 'System.Net.Http, Version = 4.2.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Die angegebene Datei wurde vom System nicht gefunden.
Source = StackTrace: bei Microsoft.Azure.Documents.Client.DocumentClient.Initialize (Uri serviceEndpoint, ConnectionPolicy connectionPolicy, Nullable 1 desiredConsistencyLevel) at Microsoft.Azure.Documents.Client.DocumentClient..ctor(Uri serviceEndpoint, String authKeyOrResourceToken, ConnectionPolicy connectionPolicy, Nullable1 gewünschteConsistencyLevel)

Innere Ausnahme 1: FileNotFoundException: Datei oder Assembly 'System.Net.Http, Version = 4.0.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Die angegebene Datei wurde vom System nicht gefunden.

Ich habe absolut keine Ahnung, warum die System.Net.Http-Assembly überhaupt nicht gefunden wird - in meinem Klassenbibliotheksprojekt gibt es sogar einen Assemblyverweis auf die .Net Framework-Assembly „System.Net.Http 4.0.0.0“.

Was ich auch nicht verstehe ist, dass es diese seltsame Bindungsumleitung zu 4.2.0.0 gibt - woher kommt diese? Um dies zu umgehen, habe ich versucht, der app.config des Service Fabric Service (der die Klassenbibliothek belegt) die folgende Umleitung hinzuzufügen:

Aber immer noch kein Unterschied, ich bekomme immer noch den Fehler zur Laufzeit.

Hat jemand eine Ahnung? Hat jemand ein solches Problem gesehen?

Danke und Grüße, OliverB

Das Problem, mit dem Sie konfrontiert sind, hängt mit Visual Studio zusammen, insbesondere mit 2017, das mit ausgeliefert wird System.Net.Http v4.2.0.0. System.Net.HttpWenn Sie jedoch die neue Methode anwenden, mit der Referenzen über NuGet erstellt werden sollen, enthält die neueste Version 4.3.3 die DLL-Version 4.1.1.2.

Das Problem ist, dass VS zur Erstellungszeit und zur Laufzeit Ihre Referenz ignoriert und versucht, auf die ihm bekannte DLL zu verweisen.

Wie man es repariert:

• Stellen Sie sicher, dass alle Verweise auf System.Net.Http über NuGet erfolgen
• Build-Time-Fehler: Ändern Sie die Erweiterung von System.Net.Http.dll (oder verschieben Sie sie an einen anderen Ort ... entfernen Sie sie im Grunde genommen), die mit VS 2017 ( c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\) geliefert wird . Wenn Sie eine andere Version haben, unterscheidet sich der Pfad geringfügig, allerdings nicht sehr

• Laufzeitfehler: Fügen Sie eine Assembly-Bindungsumleitung hinzu

Wenn Sie online auf Google suchen, werden Sie einige offene Probleme mit Microsoft finden, die hoffentlich in Zukunft behoben werden.

Hoffe das hilft.

Aktualisieren:

Bei der Suche nach dauerhaften Korrekturen für dieses Problem bei den Build-Agenten wurde festgestellt, dass bei der Migration auf das neue NuGet PackageReference-Modell (in .csprojnicht in packages.config) die Funktionsweise tendenziell besser funktioniert. Hier ist ein Link zu der Anleitung zur Durchführung dieses Upgrades: https://docs.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-reference

Das Entfernen der Bindungsumleitung hat bei mir funktioniert. Sie können versuchen, sie zu entfernen:

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

Eine Ergänzung zu der Antwort, die @AndreiU bereits gegeben hat, und wie Laufzeitfehler lokal reproduziert werden.

Beim Bereitstellen in Azure, nicht lokal, wurde der folgende Laufzeitfehler angezeigt.

Datei oder Assembly 'System.Net.Http, Version = 4.2.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Das System kann die angegebene Datei nicht finden. "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" at Company.Project.Service.CompanyIntegrationApiService..ctor (Uri baseAddress) \ r \ n at Company.Project .BackOffice.Web.Controllers.OrderController..ctor () in C: \ projects \ company-project \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ OrderController.cs: Zeile 30 \ r \ n bei lambda_method ( Closure) \ r \ n bei System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (HttpRequestMessage-Anforderung, HttpControllerDescriptor controllerDescriptor, Typ controllerType) "}} Kultur = neutral, PublicKeyToken = b03f5f7f11d50a3a 'oder eine seiner Abhängigkeiten. Das System kann die angegebene Datei nicht finden. "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" at Company.Project.Service.CompanyIntegrationApiService..ctor (Uri baseAddress) \ r \ n at Company.Project .BackOffice.Web.Controllers.OrderController..ctor () in C: \ projects \ company-project \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ OrderController.cs: Zeile 30 \ r \ n bei lambda_method ( Closure) \ r \ n bei System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (HttpRequestMessage-Anforderung, HttpControllerDescriptor controllerDescriptor, Typ controllerType) "}} Kultur = neutral, PublicKeyToken = b03f5f7f11d50a3a 'oder eine seiner Abhängigkeiten. Das System kann die angegebene Datei nicht finden. "," ExceptionType ":" System.IO.FileNotFoundException "," StackTrace ":" at Company.Project.Service.CompanyIntegrationApiService..ctor (Uri baseAddress) \ r \ n at Company.Project .BackOffice.Web.Controllers.OrderController..ctor () in C: \ projects \ company-project \ src \ Company.Project.BackOffice.Web \ Controllers \ Order \ OrderController.cs: Zeile 30 \ r \ n bei lambda_method ( Closure) \ r \ n bei System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (HttpRequestMessage-Anforderung, HttpControllerDescriptor controllerDescriptor, Typ controllerType) "}}

Als ich anfing, Baugruppen zu betrachten, konnte ich feststellen, dass mein Webprojekt und mein Serviceprojekt auf verschiedene Versionen abzielten System.Net.Http .

Webprojekt:

Serviceprojekt:

Es ist leicht zu glauben, dass dies durch eine Nichtübereinstimmung in den Versionen verursacht wird, aber der Schlüssel hier ist, den Fehler zu untersuchen The system cannot find the file specified..

Wenn Sie sich die Pfadeigenschaft ansehen, sehen Sie, dass das Webprojekt auf eine .NET Framework-Assembly abzielt, während der Dienst auf eine Assembly aus Visual Studio 2017 abzielt. Da auf dem Server Visual Studio 2017 nicht installiert ist, tritt der Laufzeitfehler auf.

Webpfad:

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Net.Http.dll

Servicepfad:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Net.Http.dll

Etwas so einfache wie Einstellung Copy Localzu truedem Problem jedoch nicht in allen Fällen zu beheben.

Um den Fehler auf Ihrem lokalen Computer zu reproduzieren, entfernen Sie einfach den erforderlichen System.Net.Http.dll aus dem Visual Studio-spezifischen Ordner. Dies gibt Ihnen den Laufzeitfehler und wahrscheinlich einige Buildfehler. Nachdem diese behoben sind, sollte alles funktionieren, zumindest für mich.

Wenn Sie installiert haben , System.Net.Httpüber NuGetPrüfung , die Montage wird durch einen Blick auf die verwendete .csprojVersion. System.Net.Http 4.3.4gibt die folgende Baugruppe zum Beispiel:

<Reference Include="System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
  <HintPath>..\packages\System.Net.Http.4.3.4\lib\net46\System.Net.Http.dll</HintPath>
  <Private>True</Private>
  <Private>True</Private>
</Reference>

Wenn Sie einen Build-Server wie Jenkins, TeamCity oder AppVeyor verwenden, ist .dllmöglicherweise auch die fehlende Laufzeit vorhanden. In diesem Fall ist es möglicherweise nicht hilfreich, die NuGet-Version von System.Net.Http zu verwenden oder die fehlenden .dlllokal zu löschen . Um diesen Fehler zu beheben, schauen Sie sich die Version an, die nicht gefunden wurde, und die spezifische PublicKeyToken. Erstellen Sie anschließend eine verbindliche Weiterleitung in einem Web.configoder App.configabhängig von Ihrem Projekt. In meinem Fall möchte ich stattdessen 4.0.0.0 verwenden:

<dependentAssembly>
  <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0" />
</dependentAssembly>

Ein guter Github-Thread zu diesem Thema:

https://github.com/dotnet/corefx/issues/22781

Was ich getan habe, um das Problem zu beheben, war, alle Bindungen aus der web.config zu entfernen und a

Update-Package -reinstall

Dadurch wurden einige der alten Bindungen entfernt, die wahrscheinlich nicht vorhanden sein müssen, und es wurde tatsächlich eine gute Reinigung durchgeführt.

Ich habe gerade System.Net.Httpmit NuGet installiert . Sie können es hier greifen:

https://www.nuget.org/packages/System.Net.Http/

Das ASP.NET MVCProjekt, an dem ich arbeite .NET 4.6.1. Es funktioniert perfekt auf meinem Computer beim Debuggen IIS Expressmit Visual Studio 2019.

Das Problem trat auf, wenn versucht wurde, die in Azure bereitgestellte Anwendung auszuführen. Ich habe diesen Fehler erhalten:

Datei oder Assembly 'System.Net.Http, Version = 4.2.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' oder eine ihrer Abhängigkeiten konnte nicht geladen werden.

Was in meinem Fall wirklich funktioniert hat, war das Öffnen der .csproj-Datei und das Suchen nach System.Net.Httpwie im folgenden Screenshot ...

Stellen Sie sicher, dass die .csprojDatei die folgende Version hat 4.1.1.3:

<Reference Include="System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">

Das zeigt <HintPath>tatsächlich auf den ..\packagesOrdner von Nuget, das heißt, dies ist die von Nuget installierte echte Version. Nach der Bereitstellung wird diese spezielle Version auch auf der Serverseite wiederhergestellt, und alles sollte mit einer Bindungsumleitung funktionieren.

... und so sollte die Bindungsumleitung diese spezifische Version Web.configwie folgt erwähnen :

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.1.1.3" />
</dependentAssembly>

Dies hat das Problem in meinem Fall nach einigen Commits bei Azure Kudu behoben . Die Azure-Website wurde schließlich fehlerfrei gestartet.

Dieser Fehler ist aufgetreten, als ich einen Webdienst auf einem unserer Server bereitgestellt habe. Das Projekt zielte auf das .NET Framework 4.7.2 ab, das nicht auf dem Server installiert war. Durch die Installation des 4.7.2-Frameworks auf dem Server wurde das Problem behoben.

Die Antwort von Andrei U führte zu meiner Erlösung. Die Argumentation stimmte jedoch nicht mit meinem Fall überein. Für Leute, die sich im selben Szenario wie ich befinden:

Es war ein Laufzeitfehler (keine Erstellungszeit), bei dem die Erstellung erfolgreich war, aber auf einem Computer, jedoch nicht auf dem Server, funktionierte. Lösung: - System.Net.Http-Paket hinzugefügt. - Benennen Sie die Datei um: C: \ Programme (x86) \ Referenzassemblies \ Microsoft \ Framework.NETFramework \ v4.7.2 \ System.Net.Http.dll (z. B. umbenennen in: System.Net.Http.dll.BAK) auf dem Server erstellen.

Ich hatte und habe keine Assembly-Weiterleitungen für diese DLL

Eine einfache Lösung fand ich, die das Ziel-Framework für Web-Projekte auf 4.6 herunterstufte.

Ich erstelle einen Client und eine Webanwendung, wobei der Client das .net Framework 4.7.1 und das Web das gleiche hat und ich vor dem gleichen Problem stehe, wenn ich das Ziel .net Framework für das Web herunterstufe, funktioniert es für mich.

Nachdem ich einige Tage damit zu kämpfen hatte, wurde endlich das Problem .Net 4.7.2 / System.Net.Http für mein Projekt behoben. Zusätzlich zum Ändern der * .csproj-Datei auf die Framework-Version 4.7.2 musste ich auch app.config in den Projekten von aktualisieren

<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" />

zu:

<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.7.2" />

Ich hatte das gleiche Problem. Am Ende habe ich es gelöst, indem ich die Deploy-FabricApplication.ps1 in so etwas geändert habe

$binFolder = "$LocalFolder\..\..\..\..\Bin"

$httpDllLocation = "$binFolder\System.Net.Http.dll"
$codeFolder = "$ApplicationPackagePath\[ProjectName].ServicesPkg\Code"
$configFile = "$codeFolder\[ProjectName].Services.exe.config"

Copy-Item $httpDllLocation -Destination $codeFolder 

$appConfig = [xml](cat $configFile)
$appConfig.configuration.runtime.assemblyBinding.dependentAssembly | foreach {

    $name = $_.assemblyIdentity.name
    #Write $name
    if($name -eq 'System.Net.Http')
    {
        Write 'System.Net.Http changed'

        $_.bindingRedirect.newVersion = '4.2.0.0'
    }
}
$appConfig.Save($configFile)

Ich habe eine 4.2.0.0 System.Net.Http.dll gefunden, die x64 ist. Vor dem Bereitstellen dieses Skripts wird die DLL in das Paketverzeichnis kopiert und die Konfigurationsdatei so geändert, dass diese Datei explizit verwendet wird. Ich habe auch einen Blog über meine System.Net.Http-Probleme unter http://gertjanvanmontfoort.blogspot.nl/2017/11/systemnethttp-dll-version-problems.html geschrieben

Vergessen Sie nicht, den [Projektnamen] durch Ihren eigenen Projektnamen zu ersetzen

Hoffe das hilft, zögern Sie nicht zu fragen

Für mich war etwas wirklich Seltsames. Benötigte Stunden des Debuggens, nachdem festgestellt wurde, was das Problem war. Dies geschah nicht lokal, sondern nur, wenn Jenkins zum Erstellen des Projekts verwendet wurde.

Ich hatte eine kleine Bibliothek mit Dotnet Standard 2.0 und das Hauptprojekt war das WCF-Projekt, das auf normalem .NET basiert (meins war speziell v4.6.1). Aber in der Startklasse der Dotnet-Standardbibliothek hatte ich einen Code, der so aussah:

public static class CoreModule
{
    public static IServiceCollection AddStaticDataConfiguration(
        this IServiceCollection services, Func<IServiceProvider, IStaticDataConfiguration>  staticDataConfiguration) 
    {  
        services.TryAddSingleton(staticDataConfiguration);
        services.TryAddSingleton<Func<HttpClient>>(x =>
        {
            var configuration = staticDataConfiguration(x);

            return configuration.ClientResolver ?? (() => new HttpClient());
        });
        return services;
    }
}

Die IStaticDataConfiguration-Schnittstelle sieht wie folgt aus:

public interface IStaticDataConfiguration
{
    //..... some stuff

    Func<HttpClient> ClientResolver { get; set; }
}  

Diese Schnittstelle befindet sich innerhalb der Dotnet-Standardbibliothek, während sich die Implementierung außerhalb der Dotnet-Bibliothek befindet (sie befindet sich im WCF-Projekt).

Von außerhalb der Bibliothek habe ich die folgende AddStaticDataConfigurationMethode aufgerufen:

serviceCollection.AddStaticDataConfiguration(p =>
{
    var staticDataConfig = p.GetService<IStaticDataConfiguration>();
    return new StaticDataProviderConfiguration
    {
        //...some other stuff
        ClientResolver = () => restRequestFactory.GetInstrumentedClient("StaticDataService") //this returns an HttpClient
    };
});

Das Problem ist, dass ich ein Func<HttpClient>von einem normalen .NET-Projekt an eine Dotnet-Standardbibliothek übergebe, die Dotnet-Standard aus irgendeinem verrückten Grund nicht mag und vielleicht denkt, dass HttpClientes aus verschiedenen Klassen stammt, was dazu führt, dass System.Net.Http 4.x.x.xkeine gefundene Ausnahme ausgelöst wird . Wenn der Code entfernt wird, um ein HttpClientaus einem normalen .NET-Projekt nicht zu akzeptieren, sondern ein neues funcin der Bibliothek selbst zu erstellen, ist es glücklich und funktioniert einwandfrei. Hoffe das könnte jemand anderem helfen, da dieser Fehler aus so vielen Gründen auftritt :)

Meine Lösung war ähnlich wie bei @ Raquib. Mein Projekt war 4.7.2 und funktionierte auf meinem PC einwandfrei. Bei jeder Bereitstellung auf unserem Entwicklungsserver wurde das in der Frage erwähnte Problem angezeigt. Es stellte sich heraus, dass die höchste .net-Version auf dem Server 4.6.1 war. Ein Downgrade meines Projekts auf 4.6.1 hat das Problem behoben. Ein Upgrade der .net-Version des Servers war für mich keine Option.

Ich glaube, ein Teil der Antwort ist in der Dokumentation von Microsoft zu finden .

Wenn Sie in Visual Studio eine Desktop-App erstellen, die auf .NET Framework 4.5.1 oder eine neuere Version abzielt, verwendet die App die automatische Bindungsumleitung.

Wie die Antwort von @Vivek Sharma zeigt, wird Folgendes entfernt:

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

Das Problem wurde in 3 solchen Fällen in meiner App behoben. Wenn Sie die DLL mit Powershell untersuchen, zum Beispiel:

 ([system.reflection.assembly]::loadfile("C:\MyApp\bin\System.Net.Sockets.dll")).FullName

Ausgänge

System.Net.Sockets, Version = 4.0.0.0

Offensichtlich wird eine verbindliche Umleitung zu 4.2.0.0nicht funktionieren, da wir 4.0.0.0in den Bin ausgeben .

Es lohnt sich auch, den GAC zu überprüfen, um festzustellen, ob die Baugruppe auch dort fehlt:

 gacutil -l System.Net.Sockets

In meinem Fall fehlte die jeweilige Version auch im GAC. Wenn sich die DLL im GAC befand, sollte sie im Assembly-Bindungsprozess gefunden worden sein .

Löschen Sie zuerst aus Ihrem lokalen Dateisystem:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\Syste.Net.Http.dll

Entfernen Sie dann alle Referenzen in Projects und fügen Sie die 4.0-Referenz hinzu.
Dies löste mein Problem für mich.