Aws-lambda-dotnet: Nuget-Abhängigkeit löst System.IO.FileNotFoundException aus

Ich habe auch den Quellcode für libphonenumber heruntergeladen und diesen csproj als Projektreferenz in einer Lambda-Lösung hinzugefügt. Es lässt sich gut bauen, aber sobald ich das Lambda über das Testtool aufrufe, tritt derselbe Fehler auf.

Ich habe auch einen Fehler im libphonenumber-Projekt geöffnet, da ich nicht sicher bin, auf welcher Seite das Problem liegt:
https://github.com/twcclegg/libphonenumber-csharp/issues/95

Hallo @rianjs , wir untersuchen das. Ich habe bestätigt, dass es im Testtool nicht funktioniert, aber dieselbe Bibliothek funktioniert in einer Konsolen-App – wie Sie in der Ausgabe für das andere Repo angeben. Ich habe auch verifiziert, dass einige andere Bibliotheken mit dem Testtool funktionieren, also werde ich jetzt weiter untersuchen, warum diese nicht funktioniert. Lassen Sie mich wissen, wenn Sie Updates auf Ihrer Seite haben. Danke, dass du es gemeldet hast.

Wenn der Code offen wäre, hätte ich ihn gerne selbst durchgearbeitet. ;P

Ich vermute, dass es in einer "echten" Lambda-Umgebung gut funktioniert.

Das Problem:

Ich habe ein ähnliches Problem, aber mit einer anderen Bibliothek. Ich habe ein Netcore2.1-Lambda-Projekt, das auf Microsoft.EntityFrameworkCore 2.2.3 und Microsoft.EntityFrameworkCore.Sqlite 2.2.3 verweist. Bei der Ausführung in Visual Studio mit dem Mock Lambda Test Tool wird die folgende Ausnahme ausgelöst:

System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Data.Sqlite, Version=2.2.3.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.
   at AWSLambda_EfCoreTest.Function.FunctionHandler(String input, ILambdaContext context)

Ich habe bestätigt, dass diese Lambda-Funktion in der echten Cloud-basierten Lambda-Umgebung von AWS bereitgestellt und erfolgreich ausgeführt werden kann.

Siehe das kleine Reproduktionsprojekt im Anhang

Die Quelle:

Ich habe das aws-lambda-dotnet-Repository geklont und das Testtool ausgeführt. Ich habe einen neuen Komponententest erstellt, um das Tool aufzurufen und in den Code einzusteigen. Das Testtool löst die Ausnahme während der Methode Amazon.Lambda.TestTool.Runtime::LambdaAssemblyResolver::OnResolving aus. Diese Methode kann AssemblyName = Microsoft.Data.Sqlite nicht auflösen und gibt null zurück. Diese Methode ist die letzte Methode, die aufgerufen wird, bevor LoadContext eine System.IO.FileNotFoundException aufrufen muss, wenn die Assembly nicht aufgelöst wird.

Die in einem anderen Problem gepostete Lösung funktioniert. In dieser Ausgabe hat der Autor einfach auf eine Version 2.1.* heruntergestuft. Wenn wir für beide ef-Core-Referenzen auf 2.1.8 herunterstufen, funktioniert das Testtool wieder. Dies ist jedoch keine Option für mich. Ich versuche, neue Funktionen in ef core 2.2.* zu nutzen. IMO sollte das Tool in der Lage sein, Assemblys zu laden, die auch in Lambda unterstützt werden.

Dieses offene Problem im Corefx-Repo kann Hinweise auf das zugrunde liegende Problem geben.

Ich würde weiter suchen, aber mir fehlt die Zeit. Irgendwelche Ideen?

AWSLambda_NetCore21-EfCore22Test.zip

Ich habe Version 0.9.2 veröffentlicht, die eine Änderung bei der Suche nach Abhängigkeiten enthält. Mit dieser Änderung konnte ich mit diesem Tool eine Lambda-Funktion ausführen, die libphonenumber verwendete.

Wenn Sie Visual Studio und das AWS Toolkit for Visual Studio verwenden, sollte das Update auf 0.9.2 automatisch erfolgen, wenn Sie Ihre Lösung das nächste Mal öffnen, vorausgesetzt, Sie sind online.

Auch @rianjs , der Code für das Mock-Test-Tool ist Open Source und kann in diesem Repo unter https://github.com/aws/aws-lambda-dotnet/tree/master/Tools/LambdaTestTool gefunden werden

Hallo @normj ,

Danke für die bisherige Hilfe. Ich habe das Tool auf 0.9.2 aktualisiert. Ich bekomme immer noch System.IO.FileNotFoundException. Können Sie mit meinem oben aufgeführten Beispielprojekt replizieren?

Im Moment kann ich das umgehen, indem ich meine Lambda-Funktionen für die lokale Entwicklung über eine Konsolen-App starte.

Hm, bei mir funktioniert das immer noch nicht.

Mein vorheriger Kommentar, den ich bearbeitet habe, war falsch. Letztes Problem war nur PEBKAC. Die LibPhoneNumber-Assembly wurde problemlos gefunden.

Ich habe dieses Problem in 0.9.2 mit einem Nuget-Paket, auf das von einem anderen Projekt verwiesen wird, von dem mein Lambda-Projekt abhängig ist.

Ich habe das gleiche Problem in 0.9.2.
Das Testtool hat bereits die Microsoft.Extensions.* 2.1 geladen. , also schlägt es fehl, wenn wir Microsoft.Extensions verwenden möchten. 2.2.*.

Können Sie dieses Problem lösen?

@jiabiao Ich habe das gleiche Problem.

System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=2.2.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. Could not find or load a specific file. (Exception from HRESULT: 0x80131621)

Version 0.9.2

@AngelVenchev Könnten Sie versuchen, die Version von 2.2 auf 2.1 zu ändern? Das hat bei mir bei einem ähnlichen Problem funktioniert. Kann damit zusammenhängen, dass Lambda .Net Core 2.2 nicht unterstützt

@IdresAhmed , das habe ich letztendlich getan, obwohl ich jetzt zwei Versionen habe, 2.2 für die Bereitstellung in Lambda und 2.1 für die lokale Ausführung.

@IdresAhmed @AngelVenchev Ich habe diese Feature-Anfrage geöffnet, die das Problem der Verwendung verschiedener Versionen von Microsoft.Extensions.* behandeln würde, die dann von der ASP.NET Core-Web-App des Testing-Tools geladen wurden

Ich habe das gleiche Problem mit der Google.Apis.Auth-Abhängigkeit. Es funktioniert gut, wenn es in AWS bereitgestellt wird, aber wenn ich versuche, es lokal mit dem Testtool auszuführen, erhalte ich diesen Fehler. Ich verwende .NET Core 2.1 und das Testtool 0.9.2.

System.IO.FileLoadException: Datei oder Assembly „Google.Apis.Auth, Version=1.35.1.0, Culture=neutral, PublicKeyToken=4b01fa6e34db77ab“ konnte nicht geladen werden. Eine Operation ist im jetzigen Zustand nicht legal.

Ich bin auf dieses Problem gestoßen und glaube, ich habe möglicherweise die Ursache für "Eine Operation ist im aktuellen Zustand nicht legal." gefunden. Bitte entschuldigen Sie die schlechte Formatierung in der Antwort unten.

Tools\LambdaTestTool\Amazon.Lambda.TestTool\Runtime\LambdaAssemblyResolver.cs OnResolving Line 79
und genauer Zeile 93:

return this.loadContext.LoadFromAssemblyPath(assemblies[0]);

Das Problem hier ist, dass, wenn eine Assembly mehrere Laufzeiten enthält, nur die erste in der Liste ausgewählt wird. In einigen Fällen handelt es sich um eine Unix-Laufzeit, die nicht mit einem Windows-Computer kompatibel ist, der in meinem Fall das Betriebssystem ist, das ich für die Entwicklung verwende.

Dies verursacht bei der Bereitstellung kein Problem, da die Abhängigkeiten beim Veröffentlichen des Projekts ordnungsgemäß gerendert werden.

Wenn beispielsweise ein Projekt zum Debuggen kompiliert wird, wird eine Datei mit dem Namen „[projectName].deps.json“ generiert.
In dieser Datei sah ich in meinem Fall dies als den ersten Eintrag für die Bibliothek, auf die ich mich bezog:

"runtimeTargets": {
    "runtimes/unix/lib/netstandard1.6/Microsoft.Management.Infrastructure.Native.dll": {
    "rid": "unix",
    "assetType": "runtime",
    "assemblyVersion": "1.0.0.0",
    "fileVersion": "1.0.0.0"
},

Um meinen Verdacht zu überprüfen, habe ich das Projekt ausgeführt und in Visual Studio debug->windows->modules geöffnet und konnte sehen, dass die geladene Assembly tatsächlich falsch war. Der oben erwähnte Code hat nur die erste Abhängigkeit in der Liste übernommen, die auf einer Windows-Plattform nicht funktioniert.

Für meine Bedürfnisse konnte ich die Startzeile 78 von LambdaAssemblyResolver.cs OnResolving wie folgt ändern:

if (library != null){
        var deps = library.RuntimeAssemblyGroups.Distinct().Count() > 1
        ? library.RuntimeAssemblyGroups.Where(x => x.Runtime.StartsWith("win") && x.Runtime.Contains("x64")).SelectMany(g => g.AssetPaths)
        : library.RuntimeAssemblyGroups.SelectMany(g => g.AssetPaths);
        var wrapper = new CompilationLibrary(
                library.Type,
                library.Name,
                library.Version,
                library.Hash,
                deps,
                library.Dependencies,
                library.Serviceable);
        var assemblies = new List<string>();
        this.assemblyResolver.TryResolveAssemblyPaths(wrapper, assemblies);
        if (assemblies.Count > 0)
        {
            return this.loadContext.LoadFromAssemblyPath(assemblies.FirstOrDefault(x => !x.EndsWith(".Native.dll")));
        }
}

Ich habe einen Filter hinzugefügt, um nur Laufzeitversionen abzurufen, die für Win 64 und höher erstellt wurden, und native Binärdateien auszuschließen.

Ich habe dies nicht als PR eingereicht, da es nur "gut genug für mich" und meinen speziellen Fall ist, aber so etwas in Kombination mit Betriebssystem- und Plattformerkennung würde ein ordnungsgemäßes Laden der Assembly ermöglichen.

Ich bin mir nicht sicher, ob dies zu einer Funktionsanfrage oder einem Fehler eskaliert werden sollte.

Auch wenn ich irgendetwas tun kann, um zu diesem Projekt beizutragen, lassen Sie es mich bitte wissen.

Habe ein ähnliches Problem.

Wir versuchen, Swagger hinzuzufügen: <PackageReference Include="Swashbuckle.AspNetCore" Version="4.0.1" />

Es funktioniert in der bereitgestellten asp.net-App, die sich hinter dem API-Gateway befindet.

Im Testtool wird diese Ausnahme jedoch ausgelöst.

Es ist sehr einfach, eine serverlose Standardprojektvorlage zu reproduzieren, die obige Assembly hinzuzufügen und die Zeilen services.AddSwaggerGen() und app.UseSwagger(); in den ConfigureServices- bzw. Configure-Methoden hinzuzufügen.

Starten Sie die App mit dem Mock Lambda-Tool. Stellen Sie eine beliebige Anfrage mit der API Gateway-Vorlage aus dem Tool. Es wird die FileNotFoundException werfen

Ich habe das gleiche Problem

System.IO.FileNotFoundException: Could not load file or assembly 'XYZ, Version=1.0.0.32, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.
   at SomeClass.Function..ctor()

wobei XYZ .NET Standard 2.0 lib und Lambda-Projekt Core 2.1 ist

Gleicher Fehler

System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Extensions.DependencyInjection, Version=2.2.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. Could not find or load a specific file. (Exception from HRESULT: 0x80131621)
   at Namespace.Function..ctor()

Hallo, ich habe das gleiche Problem, irgendwelche Hilfe bei der Lösung?

Gleiches Problem heute mit System.Data.SqlClient.dll

Ich bin nur neugierig darauf ... aber ich habe ProcMon ausgeführt und den Pfad System.Data.SqlClient.dll beobachtet - (die Datei, mit der ich in diesem Zusammenhang Probleme habe). -2.1.exe versucht, CreateFileMapping gegen System.Data.SqlClient.dll durchzuführen, es erhält ein Ergebnis von FILE LOCKED WITH ONLY READERS. Was nach weiteren Recherchen zeigt, dass es einen Fehler "Datei oder Assembly konnte nicht geladen werden" verursachen kann. Ich dachte, dass ich bis zum Neustart von Visual Studio 2019 als Administrator diesen Fehler beheben könnte, aber kein solches Glück. Ich vermute, dass andere, die dieses Problem haben, dieses Problem auch mit den Assemblys in den Lambdas finden werden, die sie ebenfalls zu debuggen versuchen. Ich hoffe, das hilft jemandem. Ich suche noch nach einer Abhilfe.

Ok, ok, ok .. Für mich war dieses Problem darauf zurückzuführen, dass ich die Version des System.Data.SqlClient Nuget-Pakets auf 4.5.1 senken musste. Aus irgendeinem Grund erzeugt alles Höhere den Fehler "Datei oder Assembly konnte nicht geladen werden", um den es in diesem Thread geht. Die Version 4.6 und höher gibt mir diesen Fehler, wenn ich lokal mit dem Lambda-Debugging-Tool debugge.

Wollte mal ein Statusupdate geben. Ich arbeite derzeit an der .NET Core 3.1-Version dieses Tools für die kommende .NET Core 3.1 Lambda-Laufzeit. Die Arbeit dafür kann im mock-testtool-31 verfolgt werden.

In dieser Version verwende ich den AssemblyDependencyResolver , der in .NET Core 3.0 hinzugefügt wurde, um die Lambda-Funktion in einem separaten AssemblyLoadContext zu laden. Dies hilft bei diesen Problemen, wenn die Lambda-Funktion, die eine andere Version einer Assembly verwendet, dann vom Testtool geladen wurde.

Wie können wir 3.1 testen?

Ich hatte das gleiche Problem mit meinem supereinfachen Vorlagenprojekt,
System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=3.1.3.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. Could not find or load a specific file. (Exception from HRESULT: 0x80131621) at AWSLambda1.Functions.MyFunction..ctor()
Auch mit Microsfot.Extensions.Configuration.Abstractions (neueste 3.1.3)

Nachdem ich alle Kommentare gelesen habe, verwende ich dieselbe Lösung wie einige von Ihnen. Ich musste meine Pakete und die von ihnen referenzierten Pakete auf eine niedrigere Version herunterstufen. In diesem Fall verwende ich 2.1.

Das ist, was ich jetzt habe, damit mein Mock-Tool funktionieren kann.

Nur um einige Fakten zu diesem Thema in Erinnerung zu rufen.

• Projekt kompiliert ohne Fehler
• Testprojekt läuft erfolgreich
• Das Mock-Tool funktioniert nicht, wenn Code ausgeführt wird, der die DLL verwendet.

Dies ist die Zeile, die in meinem Fall den Fehler verursacht.
public MyFunction() : this(StartUp.Container.BuildServiceProvider()) {}
Das ist mein Startup.cs

using AWSLambda1.Config;
using AWSLambda1.Services;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;

namespace AWSLambda1
{
    public class StartUp
    {
        public static IServiceCollection Container => ConfigureServices(LambdaConfiguration.Configuration);

        private static IServiceCollection ConfigureServices(IConfigurationRoot root)
        {
            var services = new ServiceCollection();

            var a = root.GetSection("MySection");
            services.Configure<EnvMySection>(options =>
                root.GetSection("MySection").Bind(options));

            var b = new MyFunctionEnvironment() { Something = LambdaConfiguration.Configuration["Hello"] ?? "" };
            services.AddSingleton(b);
            services.AddTransient<IMyService, MyService>();
            return services;
        }
    }
}

Version 0.10.0 wurde heute sowohl für .NET Core 2.1 als auch für .NET Core 3.1 veröffentlicht, die nun den Lambda-Code in einem separaten AssemblyLoadContext lädt. Ich glaube, das wird viele der hier gemeldeten Probleme beheben. Ich werde dieses Thema schließen, da es alt ist und ich glaube, dass es mehrere separate Probleme gibt. Wenn nach der Verwendung der neuen Version immer noch ein Problem besteht, öffnen Sie bitte ein separates Problem, um es einfacher nachverfolgen zu können.

Danke @normj und herzlichen Glückwunsch, werde ich testen

@normj
Sie da. Ich hatte vor 6 Tagen die gleichen Probleme. Ich habe versucht, alle Informationen, die ich im letzten Beitrag dieses Threads hatte, abzudecken. Ich glaube nicht, dass dieses Problem gelöst ist, bis wir Beweise haben.

Bist du mit 3.1 getestet?

@Edulopez Hast du die neueste Version ausprobiert, die gestern herauskam? Wenn das Problem weiterhin besteht, erstellen Sie bitte ein separates Problem mit Ihrem Repo. Ich hatte nur das Gefühl, dass dieser Thread zu unhandlich geworden ist, und ich vermute, dass viele gemeldete Probleme mit der neuen Version behoben werden.