HttpRequestMessageExtensions wurde zur Laufzeit in Azure Function nicht gefunden

8

Ich habe eine Azure Function-App, die eine vorkompilierte DLL erstellt (verwendet also normale .cs-Dateien, nicht die ältere .csx-Methode, vor VS2017). Zuvor war es auf .NET Framework 4.5.2 ausgerichtet. Ich habe es auf 4.7 aktualisiert, um einige der neuen Funktionen von C # 7 zu nutzen. Ich aktualisierte meine NuGet-Pakete, indem ich "Update-Package -Reinstall" ausführte und verifizierte, dass alle das Ziel "net47" in meiner Datei packages.config festgelegt haben.

Alles ist gut zusammengestellt. Aber wenn ich eine Funktion aufrufen, die eine der 2 HttpRequestMessageExtensions -Methoden verwendet, bekomme ich eine Ausnahme. Ein Beispiel für die Ausnahme ist dies:

%Vor%

Hier ist ein Beispiel für eine kleine Testfunktion, die den Fehler verursacht:

%Vor%

Beim Aufruf dieser Funktion mit say Postman erhalte ich die oben erwähnte Ausnahme. Ich bekomme auch eine ähnliche Methode nicht gefunden Ausnahme, wenn ich GetQueryNameValuePairs() auf der HttpRequestMessage aufrufen.

Ich habe versucht, meine NuGet-Pakete auf den neuesten Stand zu bringen, kein Unterschied. Ich habe einige Male geputzt und neu aufgebaut und neu gestartet, wobei ich darauf geachtet habe, dass ich meine bin- und obj-Verzeichnisse auffrische.

Ich bin mir nicht sicher, was das Problem sein könnte. Ich denke, ich könnte zurück auf .Net 4.5.2 herunterstufen, aber ich würde es lieber nicht tun. Zum einen möchte ich C # 7 verwenden, und für zwei möchte ich verstehen, was das Problem ist, anstatt es zu vermeiden.

Update: interessant. Das Problem scheint mit System.Net.Http zu sein. Wenn ich es auf 4.0.0 heruntersetze, funktioniert alles gut. Wenn ich es auf eine höhere Version erhöhe, bekomme ich die oben aufgeführten Probleme. Ich habe versucht, jedes meiner Pakete einzeln auf die vorherige Versionsnummer zu setzen, um das herauszufinden. Ich habe dann alle außer diesem auf die neueste Version aktualisiert und das Problem behoben.

    
Architekt 24.07.2017, 00:33
quelle

4 Antworten

5

Ich habe es auch auf meiner Seite getestet. Das Problem bezieht sich auf die neueste Version von System.Net.Http assembly (4.3.2). Wenn ich dieses Paket nicht manuell installiere oder die früheren Versionen (4.3.1 / 4.3.0) installiere, könnte die Anwendung funktionieren.

Die CreateResponse-Methode ist eine Erweiterungsmethode, die in Assembly System.Web.Http (Version 5.2.3) geschrieben wird. Es scheint, dass es nicht mit der neuesten Version von System.Net.Http kompatibel ist. Bitte überspringen Sie den Fehler einfach, indem Sie die frühere Version von System.Net.Http verwenden, und Sie können dieses Problem auch an Microsoft über den folgenden Kanal senden.

Ссылка

  

Interessant. Wenn ich über Version 4.0.0 (einschließlich 4.1.1 oder 4.3.1) komme, bekomme ich immer noch das gleiche Problem, dass ich diese Erweiterungsmethoden nicht finde.

Die Assembly wird möglicherweise nicht aktualisiert, wenn Sie die Paketversion ändern. Im Ordner bin \ Debug \ net47 konnten wir die aktuelle Version der Baugruppe überprüfen, die wir verwendet haben.

Wenn das modifizierte Montagedatum der 2/9/2017 ist, ist die Paketversion 4.3.1. Wenn das Änderungsdatum der Baugruppe der 19.04.2017 ist, lautet die Paketversion 4.3.2. Wenn die Assembly nicht die neueste Version ist, könnte es auf meiner Seite gut funktionieren.

Darüber hinaus wird das Microsoft.Asp.Net.WebApi.Client-Paket beim Erstellen einer Azure-Funktion standardmäßig installiert. System.Net.Http ist eine seiner Abhängigkeiten. Daher müssen wir das System.Net.Http-Paket nicht manuell installieren. Wenn Sie unsere Anwendung ausführen, wird NuGet für unsere Anwendung eine richtige Version von System.Net.Http auswählen.

    
Amor 24.07.2017 06:22
quelle
1

Ich hatte das gleiche Problem, dass meine Azure-Funktion lokal ausgeführt wurde und sie schließlich auf in Konflikt stehende System.Net.Http-Assemblys zurückverfolgt wurde. Ich habe meine Azure-Funktion aus einer leeren ASP.NET-Webanwendung erstellt und zuerst die System.Net.Http NuGet-Paket, das innerhalb des Projekts verwendet werden soll. Ich habe auch den Microsoft.AspNet.WebApi.Client zur Verwendung innerhalb des Projekts heruntergezogen. Es war egal, welche Version von System.Net.Http ich versuchte, mein Projekt würde kompilieren, aber fehlschlagen, wenn die Anfrage gemacht wurde.

Schließlich entfernte ich die heruntergeladenen Pakete, bereinigte den Build-Ordner und fügte nur Microsoft.AspNet.WebApi.Client hinzu. Ich habe festgestellt, dass dies für meine Version von .NET Framework automatisch auf meiner Maschine auf System.Net.Http verwiesen. (C: \ Programme (x86) \ Reference Assemblies \ Microsoft \ Framework.NETFramework). Dieses kompilierte erfolgreich und ich konnte Anforderungen an die Funktion ohne Ausnahmen stellen.

    
IsolatedStorage 10.08.2017 01:18
quelle
1

Anhand von @ Aaron-Newtons Erkenntnissen habe ich festgestellt, dass mein Problem auf mein Azure-Funktionen-Projekt zurückzuführen war, das auf eine .Net-Standard-2.0-Klassenbibliothek verweist. Ich habe es auf .Net Framework 4.6 umgestellt und es hat wieder angefangen zu arbeiten. Scheint so, als wäre das ein Fehler in der Funktionen-Toolbox.

Ich habe hier einen Fehler mit dem Functions-Team eingereicht: Ссылка

    
Ken Sykora 02.09.2017 16:17
quelle
1

Ich hatte das gleiche Problem. Ich habe eine ganze Weile gebraucht, um das Problem zu beheben.

Die Ursache ist, dass sich das Azure-Funktionen-Projekt auf die .Net-Standardbibliothek mit einer höheren Version als 1.4 bezieht.

Wenn Sie Ihre .NET-Standardversion auf 1.4 oder niedriger bringen, wird das Problem behoben.

Aber das ist definitiv ein Bug mit Azure Functions SDK. Sie sollten es reparieren.

Ссылка

Ссылка

    
Jack Yum Cha 14.09.2017 22:57
quelle

Tags und Links