Aws-lambda-dotnet: La dependencia de Nuget está lanzando System.IO.FileNotFoundException

También descargué el código fuente de libphonenumber y agregué ese csproj como referencia de proyecto en una solución lambda. Se construye bien, pero tan pronto como invoco la lambda a través de la herramienta de prueba, ocurre el mismo error.

También abrí un error en el proyecto libphonenumber, ya que no estoy seguro de qué lado está el problema:
https://github.com/twcclegg/libphonenumber-csharp/issues/95

Hola @rianjs , estamos investigando esto. Confirmé que no funciona en la herramienta de prueba, pero la misma biblioteca funcionará en una aplicación de consola, como indica en el problema para el otro repositorio. También verifiqué que algunas otras bibliotecas funcionan con la herramienta de prueba, así que ahora continuaré investigando por qué esta no funciona. Avíseme si tiene actualizaciones de su lado. Gracias por informarlo.

Si el código estuviera abierto, habría estado feliz de resolverlo yo mismo. ;PAGS

Supongo que funciona bien en un entorno lambda "real".

El problema:

Tengo un problema similar, pero con una biblioteca diferente. Tengo un proyecto lambda netcore2.1 que hace referencia a Microsoft.EntityFrameworkCore 2.2.3 y Microsoft.EntityFrameworkCore.Sqlite 2.2.3. Cuando se ejecuta en Visual Studio con Mock Lambda Test Tool, se lanza la siguiente excepción:

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)

He confirmado que esta función lambda se puede implementar y ejecutar con éxito en el entorno real de Lambda basado en la nube de AWS.

Ver adjunto el pequeño proyecto de reproducción

La fuente:

Cloné el repositorio aws-lambda-dotnet y ejecuté la herramienta de prueba. Creé una nueva prueba de unidad para invocar la herramienta y entrar en el código. La herramienta de prueba lanza la excepción durante el método Amazon.Lambda.TestTool.Runtime::LambdaAssemblyResolver::OnResolver. Este método no puede resolver AssemblyName = Microsoft.Data.Sqlite y devolverá un valor nulo. Este método es el último método llamado antes de que LoadContext tenga que llamar a System.IO.FileNotFoundException si el ensamblado no se resuelve.

La solución publicada en otro número funciona. En ese número, el autor simplemente bajó a una versión 2.1.*. Si cambiamos a 2.1.8 para ambas referencias principales de ef, la herramienta de prueba vuelve a funcionar. Sin embargo, esta no es una opción para mí. Estoy intentando aprovechar las nuevas funciones de ef core 2.2.*. En mi opinión, la herramienta debería poder cargar ensamblajes que también son compatibles con lambda.

Este problema abierto en el repositorio de corefx puede dar pistas sobre el problema subyacente.

Exploraría más, pero no tengo tiempo. ¿Algunas ideas?

AWSLambda_NetCore21-EfCore22Test.zip

Saqué la versión 0.9.2 que tiene un cambio en la forma en que se buscan las dependencias. Con este cambio pude ejecutar una función lambda con esta herramienta que usaba libphonenumber.

Si está utilizando Visual Studio y AWS Toolkit for Visual Studio, la actualización a 0.9.2 debería realizarse automáticamente la próxima vez que abra su solución, suponiendo que esté en línea.

También @rianjs , el código para la herramienta de prueba simulada es de código abierto y se puede encontrar en este repositorio en https://github.com/aws/aws-lambda-dotnet/tree/master/Tools/LambdaTestTool

Hola @normj ,

Gracias por la ayuda hasta ahora. Actualicé la herramienta a 0.9.2. Sigo recibiendo System.IO.FileNotFoundException. ¿Puedes replicar usando mi proyecto de muestra mencionado anteriormente ?

Por ahora, puedo trabajar iniciando mis funciones lambda para el desarrollo local a través de una aplicación de consola.

Hmm, esto todavía no funciona para mí.

Mi comentario anterior, que he editado, estaba equivocado. El último problema fue solo PEBKAC. El ensamblado LibPhoneNumber se encontró bien.

Estoy experimentando este problema en 0.9.2 con un paquete nuget al que se hace referencia desde otro proyecto del que depende mi proyecto lambda.

Estoy experimentando el mismo problema en 0.9.2.
La herramienta de prueba ya cargó Microsoft.Extensions.* 2.1. , por lo que fallará si queremos usar Microsoft.Extensions. 2.2.*.

¿Puedes resolver este problema?

@jiabiao Tengo el mismo problema.

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)

Versión 0.9.2

@AngelVenchev ¿Podría intentar cambiar la versión de 2.2 a 2.1? Esto funcionó para mí para un problema similar. Puede tener que ver con Lambda que no es compatible con .Net Core 2.2

@IdresAhmed esto es lo que terminé haciendo, aunque ahora tengo dos versiones 2.2 para implementar en lambda y 2.1 para ejecutar localmente.

@IdresAhmed @AngelVenchev Abrí esta solicitud de función que abordaría el problema del uso de diferentes versiones de Microsoft.Extensions.* y luego fueron cargadas por la aplicación web ASP.NET Core de la herramienta de prueba

Tengo el mismo problema con la dependencia de Google.Apis.Auth. Funciona bien cuando se implementa en AWS, pero cuando intento ejecutarlo localmente con la herramienta de prueba, aparece este error. Estoy usando .NET Core 2.1 y la herramienta de prueba 0.9.2.

System.IO.FileLoadException: no se pudo cargar el archivo o ensamblado 'Google.Apis.Auth, Version=1.35.1.0, Culture=neutral, PublicKeyToken=4b01fa6e34db77ab'. Una operación no es legal en el estado actual.

Me encontré con este problema y creo que pude haber encontrado la causa de "Una operación no es legal en el estado actual". Disculpe el formato deficiente en la respuesta a continuación.

Tools\LambdaTestTool\Amazon.Lambda.TestTool\Runtime\LambdaAssemblyResolver.cs OnResolving Line 79
y más concretamente Línea 93:

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

El problema aquí es que si un ensamblado contiene varios tiempos de ejecución, solo seleccionará el primero de la lista. En algunos casos, este es un tiempo de ejecución de Unix que no es compatible con una máquina con Windows que, en mi caso, es el sistema operativo que estoy usando para el desarrollo.

Esto no causará ningún problema cuando se implemente porque la publicación del proyecto genera las dependencias correctamente.

Por ejemplo, cuando se compila un proyecto para su depuración, se genera un archivo denominado "[nombredelproyecto].deps.json".
En este archivo en mi caso, vi esto como la primera entrada de la biblioteca a la que hacía referencia:

"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"
},

Para verificar mis sospechas, ejecuté el proyecto y en Visual Studio abrí debug->windows->modules y pude ver que el ensamblaje que se estaba cargando era incorrecto. El código mencionado anteriormente solo tomaba la primera dependencia de la lista, que no funcionará en una plataforma de Windows.

Para mis necesidades, pude modificar LambdaAssemblyResolver.cs OnResolver la línea de inicio 78 a lo siguiente:

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")));
        }
}

Agregué un filtro para extraer solo las versiones de tiempo de ejecución creadas para Win 64 y versiones posteriores, excluyendo los binarios nativos.

No presenté esto como PR ya que solo es 'lo suficientemente bueno para mí' y mi caso específico, pero algo así en combinación con el sistema operativo y la detección de la plataforma permitiría una carga de ensamblaje adecuada.

No estoy seguro de si esto debe escalarse a solicitud de función o error.

Además, si hay algo que pueda hacer para contribuir a este proyecto, házmelo saber.

Tener un problema similar.

Estamos tratando de agregar Swagger: <PackageReference Include="Swashbuckle.AspNetCore" Version="4.0.1" />

Funciona en la aplicación asp.net implementada que está detrás de API Gateway.

Sin embargo, en la herramienta de prueba, arroja esta excepción.

Es muy fácil de reproducir, plantilla de proyecto sin servidor estándar, agregue el ensamblaje anterior, agregue las líneas services.AddSwaggerGen() y app.UseSwagger(); en los métodos ConfigureServices y Configure respectivamente.

Inicie la aplicación con la herramienta Mock Lambda. Realice cualquier solicitud utilizando la plantilla API Gateway de la herramienta. Lanzará la excepción FileNotFoundException

Tengo el mismo problema

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()

donde XYZ es .NET Standard 2.0 lib y Lambda project es Core 2.1

Mismo problema

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()

Hola tengo el mismo problema, alguna ayuda para solucionarlo?

Mismo problema hoy con System.Data.SqlClient.dll

Solo tengo curiosidad por esto... pero ejecuté ProcMon y observé la ruta System.Data.SqlClient.dll - (el archivo con el que tengo problemas en este contexto) Lo noté dos veces, cuando la herramienta de prueba dotnet-lambda -2.1.exe está intentando hacer CreateFileMapping contra System.Data.SqlClient.dll y obtiene el resultado de ARCHIVO BLOQUEADO SOLO CON LECTORES. Lo que después de más investigaciones muestra que puede causar un error "No se pudo cargar el archivo o el ensamblaje". Pensé que al reiniciar Visual Studio 2019 como administrador podría hacer que el error desapareciera, pero no tuve suerte. Sospecho que otros que tengan este problema también encontrarán este problema con los ensamblajes en Lambda que también están tratando de depurar. Espero que esto ayude a alguien. Todavía estoy buscando una solución.

Ok, ok, ok.. Para mí, este problema se debió al hecho de que tuve que bajar la versión del paquete System.Data.SqlClient Nuget a 4.5.1. Por alguna razón, cualquier cosa superior produce el error "No se pudo cargar el archivo o el ensamblaje" del que trata este hilo. La versión 4.6 y posteriores me dan ese error al depurar localmente con la herramienta de depuración de Lambda.

Quería dar una actualización de estado. Actualmente estoy trabajando en la versión .NET Core 3.1 de esta herramienta para el próximo tiempo de ejecución de .NET Core 3.1 Lambda. El trabajo para eso se puede rastrear en el mock-testtool-31 .

En esta versión, estoy usando AssemblyDependencyResolver que se agregó en .NET Core 3.0 para cargar la función Lambda en un AssemblyLoadContext separado. Eso ayudará con estos problemas si la herramienta de prueba cargó la función Lambda usando una versión diferente de un ensamblaje.

¿Cómo podemos probar 3.1?

Estaba teniendo el mismo problema con mi proyecto de plantilla súper simple,
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()
También con Microsfot.Extensions.Configuration.Abstractions (último 3.1.3)

Después de leer todos los comentarios, uso la misma solución que algunos de ustedes. Tuve que degradar mis paquetes y los mencionados por ellos a una versión inferior. En este caso estoy usando 2.1.

Esto es lo que tengo ahora para que mi herramienta Mock pueda funcionar.

Sólo para recordar algunos de los hechos sobre el tema.

• Proyecto compila sin errores
• El proyecto de prueba se ejecuta correctamente
• La herramienta simulada no funciona cuando se ejecuta el código que usa el dll.

Esta es la línea que causa el error en mi caso.
public MyFunction() : this(StartUp.Container.BuildServiceProvider()) {}
Este es mi 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;
        }
    }
}

La versión 0.10.0 se lanzó hoy para .NET Core 2.1 y .NET Core 3.1, que ahora carga el código Lambda en un AssemblyLoadContext separado. Creo que eso solucionará muchos de los problemas informados aquí. Voy a cerrar este problema porque es antiguo y creo que hay varios problemas separados. Después de usar la nueva versión, si todavía hay un problema, abra un problema por separado para que sea más fácil de rastrear.

Gracias @normj y felicidades, probaré

@normj
Hola. Tuve los mismos problemas hace 6 días. Traté de cubrir toda la información que tenía en la última publicación de este hilo. No creo que este problema se resuelva todavía hasta que tengamos pruebas.

¿Has probado con 3.1?

@Edulopez ¿Has probado la última versión que salió ayer? Si el problema persiste, cree un problema separado con su repositorio. Simplemente sentí que este hilo se había vuelto difícil de manejar y sospecho que muchos problemas informados se solucionarán con la nueva versión.