it-swarm.com.de

Seltsames Problem mit System.Net.Http 4.2.0.0 nicht gefunden

Ich habe ein seltsames Thema, das mich verrückt macht…

Ich habe ein einfaches Klassenbibliothekprojekt (Full .NET Framework, 4.6.1) mit einer Wrapper-Klasse für Funktionalität rund um Cosmos DB. Deshalb habe ich das NuGet Package 1.19.1 „Microsoft.Azure.DocumentDB“ zu diesem Projekt hinzugefügt. Ansonsten habe ich einen Verweis auf das NuGet Package 10.0.3 "Newtonsoft.Json" sowie auf ein paar "Microsoft.Diagnostics.EventFlow. *" NuGet Packages.

Bisher wird alles ohne Fehler kompiliert.

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

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

Ich bekomme diesen seltsamen Fehler zur Laufzeit:

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

Innere Ausnahme 1: FileNotFoundException: Datei oder .__ konnte nicht geladen werden. Assembly 'System.Net.Http, Version = 4.0.0.0, Kultur = neutral, PublicKeyToken = b03f5f7f11d50a3a 'oder eine seiner Abhängigkeiten. Das System kann die angegebene Datei nicht finden.

Ich habe absolut keine Ahnung, warum die System.Net.Http-Assembly überhaupt nicht gefunden wird - es gibt sogar eine Assembly-Referenz in meinem Klassenbibliothekprojekt zur .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 die? - Um diese zu umgehen, habe ich versucht, die folgende Umleitung in die app.config der Service Fabric Service (verbraucht die Klassenbibliothek):

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

Wer hat eine Ahnung? Wer hat schon ein solches Problem gesehen?

Danke und Grüße, OliverB

38
OliverB

Das Problem, mit dem Sie konfrontiert sind, hängt mit Visual Studio zusammen, insbesondere mit 2017, das mit System.Net.Http v4.2.0.0 ausgeliefert wird. Die neue Version von System.Net.Http (4.3.3) enthält jedoch die DLL-Version 4.1.1.2.

Das Problem ist, dass VS zur Buildzeit und auch zur Laufzeit Ihre Referenz ignoriert und versucht, auf die DLL zu verweisen, die es kennt.

Wie man es repariert:

  • stellen Sie sicher, dass alle Verweise auf System.Net.Http über NuGet erfolgen
  • Build Time-Fehler: Änderung der Erweiterung von System.Net.Http.dll (oder Verschieben der Datei an einen anderen Ort ... im Grunde genommen) - das mit VS 2017 (c:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\) ausgeliefert wird; Wenn Sie eine andere Version haben, wird der Pfad leicht abweichen, jedoch nicht viel
  • Laufzeitfehler: fügen Sie eine Assembly-Bindungsumleitung hinzu

Wenn Sie online bei Google suchen, werden Sie einige offene Probleme mit Microsoft in dieser Hinsicht feststellen. Hoffentlich werden sie dies in Zukunft beheben.

Hoffe das hilft.

Update:

Bei der Suche nach dauerhaften Korrekturen für dieses Problem, die auf den Build-Agenten funktionieren, ist zu beachten, dass bei einer Migration auf das neue NuGet PackageReference-Modell (in .csproj nicht in packages.config) die besten Ergebnisse erzielt werden. Hier ist ein Link zum Leitfaden für das Upgrade: https://docs.Microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-reference

74
Andrei U

Das Entfernen der Bindungsumleitung funktionierte für mich. Sie können versuchen, sie zu entfernen:

<bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />
26
Vivek Sharma

Ein Zusatz zur Antwort von @AndreiU gab bereits an und wie man Laufzeitfehler lokal reproduziert. 

Bei der Bereitstellung in Azure wurde der Laufzeitfehler unten angezeigt, nicht lokal. 

{"Message": "Ein Fehler ist aufgetreten.", "ExceptionMessage": "Beim Erstellen eines Controllers vom Typ 'OrderController' ..__ ist ein Fehler aufgetreten. Stellen Sie sicher, dass der Controller über ein parameterloses public verfügt constructor. "," ExceptionType ":" System.InvalidOperationException "," StackTrace ":" um System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (HttpRequestMessage __. controllerType)\r\n at System.Web.Http.Controllers.HttpControllerDescriptor.CreateController (HttpRequestMessage request)\r n System.Web.Http.Dispatcher.HttpControllerDispatcher.D__1. MoveNext () "," InnerException ": {" Message ":" Ein Fehler ist aufgetreten. "," ExceptionMessage ":" Datei oder .__ konnte nicht geladen werden. Assembly 'System.Net.Http, Version = 4.2. 0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a 'oder eines seiner Abhängigkeiten. Das System kann die angegebene Datei nicht finden. ".", "ExceptionType": "System.IO.FileNotFoundExcept ion "," StackTrace ":" at Company.Project.Service.CompanyIntegrationApiService..ctor (Uri baseAddress)\r\n bei Company.Project.BackOffice.Web.Controllers.OrderController..ctor () in C:\projects\company-project\src\Company.Project.BackOffice.Web\Controller\Order\OrderController.cs: Zeile 30\r\n bei Lambda_method (Closure)\r\n bei System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create (HttpRequestMessage Request, HttpControllerDescriptor controllerDescriptor, Typ ControllerType) "}}

Als ich anfing, nach Baugruppen zu suchen, konnte ich feststellen, dass mein Web- und Serviceprojekt auf verschiedene Versionen von System.Net.Http abzielte.

Webprojekt:

 enter image description here

Serviceprojekt:

 enter image description here

Es ist leicht zu glauben, dass dies auf eine Nichtübereinstimmung der Versionen zurückzuführen ist, aber der Schlüssel hier ist der Fehler The system cannot find the file specified.

Wenn Sie die path-Eigenschaft betrachten, sehen Sie, dass das Webprojekt eine .Net Framework-Assembly anvisiert, während der Dienst eine Assembly aus Visual Studio 2017 anvisiert. 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 einfaches wie das Einstellen von Copy Local auf true kann das Problem beheben, jedoch nicht in allen Fällen.

 enter image description here

Um den Fehler auf Ihrem lokalen Computer zu reproduzieren, entfernen Sie einfach den erforderlichen System.Net.Http.dll aus dem für Visual Studio spezifischen Ordner. Dadurch erhalten Sie den Laufzeitfehler und möglicherweise einige Build-Fehler. Nachdem diese behoben sind, sollte alles funktionieren, zumindest für mich. 

Wenn Sie System.Net.Http über NuGet installiert haben, prüfen Sie anhand der .csproj-Version, welche Assembly verwendet wird. System.Net.Http 4.3.4 gibt beispielsweise folgende Assembly an: 

<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 möglicherweise auch die Laufzeit .dll vorhanden. In diesem Fall hilft es möglicherweise nicht, die NuGet-Version von System.Net.Http zu verwenden oder den fehlenden .dll lokal zu löschen. Um diesen Fehler zu beheben, schauen Sie sich die Version an, die nicht gefunden wurde, und die spezifische Variable PublicKeyToken. Anschließend erstellen Sie eine Bindungsumleitung in Web.config oder App.config, abhä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 zum Thema:

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

4
Ogglas

Was ich getan habe, um das Problem zu beheben, wurde alle Bindungen aus der web.config entfernt und

Update-Package -reinstall

Dadurch wurden einige alte Bindungen entfernt, die wahrscheinlich nicht vorhanden sein mussten und tatsächlich eine gute Reinigung vorgenommen haben. 

1

Dieser Fehler ist aufgetreten, als ich einen Webservice auf einem unserer Server bereitgestellt habe. Das Projekt zielte auf .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.

1
Mark

Ich habe gerade System.Net.Http mit NuGet installiert. Sie können es hier abrufen:

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

Das ASP.NET MVC Projekt, an dem ich gerade arbeite .NET 4.6.1. Es funktioniert einwandfrei auf meinem Computer, während Sie in IIS Express mit Visual Studio 2019 debuggen.

Das Problem ist beim Versuch aufgetreten, 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 funktionierte, war das Öffnen der .csproj-Datei und das Suchen nach System.Net.Http wie im folgenden Screenshot ...

enter image description here

Stellen Sie sicher, dass die Datei .csproj die Version 4.1.1.3 hat:

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

Der <HintPath> verweist tatsächlich auf den ..\packages -Ordner von Nuget, dh 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 spezielle Version in Web.config wie erwähnt werden diese:

<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 behebt das Problem in meinem Fall nach ein paar Commits zu Azure Kud . Die Azure-Website wurde schließlich fehlerfrei gestartet.

1

Eine einfache Lösung fand ich, dass das Zielframework für das Webprojekt auf 4.6 herabgestuft wurde.

Ich erstelle einen Client und eine Webanwendung, einen Client mit .net Framework 4.7.1 und ein Web, das dasselbe hat, und ich stehe vor demselben Problem. Wenn ich ein .net Framework für das Web downgrade, ist es für mich eine Arbeit.

0
Raquib

Ich hatte das gleiche Problem. Am Ende habe ich es gelöst, indem ich Deploy-FabricApplication.ps1 in etwas ähnliches 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 der Bereitstellung 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 Probleme mit System.Net.Http geschrieben unter http://gertjanvanmontfoort.blogspot.nl/2017/11/systemnethttp-dll-version-problems.html

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

Hoffe, das hilft, fragt einfach

0
user8862383

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 Verweise in Projekte, und fügen Sie 4.0-Verweis hinzu.
Dies löste mein Problem für mich.

0
Gogo Lazarovski

Für mich war etwas wirklich seltsam. 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 wurden.

Ich hatte eine kleine Bibliothek mit dotnet Standart 2.0 und das Hauptprojekt war 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-Standardbibliothek befindet (sie befindet sich im WCF-Projekt).

Von außerhalb der Bibliothek habe ich die AddStaticDataConfiguration -Methode wie folgt 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 einen Func<HttpClient> von einem normalen .NET-Projekt an eine Dotnet-Standart-Bibliothek übergebe, die aus irgendeinem verrückten Grund Dotnet-Standart nicht mag und vielleicht denkt, dass HttpClient aus verschiedenen Klassen stammt, was dazu führt, dass System.Net.Http 4.x.x.x keine Ausnahme gefunden hat. Wenn der Code entfernt wurde, um keine HttpClient aus einem normalen .NET-Projekt zu akzeptieren, sondern eine neue func in der Bibliothek selbst zu erstellen, ist dies zufriedenstellend und funktioniert einwandfrei. Hoffe, dies könnte jemand anderem helfen, da dieser Fehler aus so vielen Gründen auftritt :)

0
Rajmond Burgaj

Meine Lösung war ähnlich wie bei @ Raquib. Mein Projekt war 4.7.2 und funktionierte einwandfrei auf meinem PC. Jedes Mal, wenn ich auf unserem Entwickler-Server bereitgestellt habe, 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.

0
Bruno