Aws-lambda-dotnet: A dependência do Nuget está lançando System.IO.FileNotFoundException

Eu também baixei o código-fonte para libphonenumber e adicionei esse csproj como uma referência de projeto em uma solução lambda. Ele é construído bem, mas assim que invoco o lambda por meio da ferramenta de teste, ocorre o mesmo erro.

Também abri um bug no projeto libphonenumber, pois não tenho certeza de que lado está o problema:
https://github.com/twcclegg/libphonenumber-csharp/issues/95

Oi @rianjs , estamos analisando isso. Confirmei que não funciona na ferramenta de teste, mas a mesma biblioteca funcionará em um aplicativo de console - como você afirma no problema do outro repositório. Também verifiquei que algumas outras bibliotecas funcionam com a ferramenta de teste, então agora continuarei investigando por que essa não funciona. Deixe-me saber se você tem atualizações do seu lado. Obrigado por denunciá-lo.

Se o código estivesse aberto, eu ficaria feliz em trabalhar com ele sozinho. ;P

Acho que funciona bem em um ambiente lambda "real".

O problema:

Eu tenho um problema semelhante, mas com uma biblioteca diferente. Eu tenho um projeto lambda netcore2.1 que faz referência a Microsoft.EntityFrameworkCore 2.2.3 e Microsoft.EntityFrameworkCore.Sqlite 2.2.3. Ao executar no visual studio com a ferramenta de teste Mock Lambda, a seguinte exceção é lançada:

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)

Confirmei que essa função lambda pode ser implantada e executada com êxito no ambiente Lambda real baseado na nuvem AWS.

Veja o pequeno projeto de reprodução em anexo

A fonte:

Eu clonei o repositório aws-lambda-dotnet e executei a ferramenta de teste. Criei um novo teste de unidade para invocar a ferramenta e entrar no código. A ferramenta de teste lança a exceção durante o método Amazon.Lambda.TestTool.Runtime::LambdaAssemblyResolver::OnResolving. Este método não pode resolver AssemblyName = Microsoft.Data.Sqlite e retornará nulo. Esse método é o último método chamado antes que o LoadContext tenha que chamar um System.IO.FileNotFoundException se o assembly não for resolvido.

A solução postada em outro problema funciona. Nessa edição, o autor simplesmente fez o downgrade para uma versão 2.1.*. Se fizermos downgrade para 2.1.8 para ambas as referências ef core, a ferramenta de teste começará a funcionar novamente. No entanto, esta não é uma opção para mim. Estou tentando aproveitar os novos recursos do ef core 2.2.*. IMO a ferramenta deve ser capaz de carregar assemblies que também são suportados em lambda.

Esse problema aberto no repositório corefx pode fornecer dicas sobre o problema subjacente.

Eu exploraria mais, mas não tenho tempo. Alguma ideia?

AWSLambda_NetCore21-EfCore22Test.zip

Eu empurrei a versão 0.9.2 que tem uma mudança na forma como as dependências são pesquisadas. Com essa alteração consegui executar uma função lambda com essa ferramenta que usava libphonenumber.

Se você estiver usando o Visual Studio e o AWS Toolkit for Visual Studio, a atualização para 0.9.2 deverá ocorrer automaticamente na próxima vez que você abrir sua solução, supondo que esteja online.

Também @rianjs , o código para a ferramenta de teste simulado é de código aberto e pode ser encontrado neste repositório em https://github.com/aws/aws-lambda-dotnet/tree/master/Tools/LambdaTestTool

Oi @normj ,

Obrigado pela ajuda até agora. Atualizei a ferramenta para 0.9.2. Ainda estou recebendo System.IO.FileNotFoundException. Você é capaz de replicar usando meu projeto de exemplo listado acima ?

Por enquanto, posso contornar iniciando minhas funções lambda para desenvolvimento local por meio de um aplicativo de console.

Hmm, isso ainda não funciona para mim.

Meu comentário anterior, que eu editei, estava errado. O último problema foi apenas PEBKAC. O assembly LibPhoneNumber foi encontrado bem.

Estou enfrentando esse problema em 0.9.2 com um pacote nuget que está sendo referenciado de outro projeto do qual meu projeto lambda depende.

Estou enfrentando o mesmo problema em 0.9.2.
A ferramenta de teste já carregou o Microsoft.Extensions.* 2.1. , então ele falhará se quisermos usar Microsoft.Extensions. 2.2.*.

Você pode resolver este problema?

@jiabiao Estou tendo o mesmo 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)

Versão 0.9.2

@AngelVenchev Você poderia tentar mudar a versão de 2.2 para 2.1? Isso funcionou para mim para um problema semelhante. Pode ter a ver com Lambda não suportando .Net Core 2.2

@IdresAhmed foi isso que acabei fazendo, embora agora tenha duas versões 2.2 para implantação em lambda e 2.1 para execução local.

@IdresAhmed @AngelVenchev Abri esta solicitação de recurso que resolveria o problema de usar versões diferentes do Microsoft.Extensions.* e foram carregados pelo aplicativo Web ASP.NET Core da ferramenta de teste

Eu tenho o mesmo problema com a dependência Google.Apis.Auth. Funciona bem quando implantado na AWS, mas quando tento executá-lo localmente com a ferramenta de teste, recebo esse erro. Estou usando o .NET Core 2.1 e a ferramenta de teste 0.9.2.

System.IO.FileLoadException: não foi possível carregar o arquivo ou assembly 'Google.Apis.Auth, Version=1.35.1.0, Culture=neutral, PublicKeyToken=4b01fa6e34db77ab'. Uma operação não é legal no estado atual.

Eu me deparei com esse problema e acredito que posso ter encontrado a causa de "Uma operação não é legal no estado atual". Por favor, desculpe a má formatação na resposta abaixo.

Tools\LambdaTestTool\Amazon.Lambda.TestTool\Runtime\LambdaAssemblyResolver.cs OnResolving Line 79
e mais especificamente a Linha 93:

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

O problema aqui é que, se um assembly contiver vários tempos de execução, ele selecionará apenas o primeiro da lista. Em alguns casos, este é um runtime unix que não é compatível com uma máquina Windows que, no meu caso, é o sistema operacional que estou usando para desenvolvimento.

Isso não causará um problema quando implantado porque a publicação do projeto renderiza as dependências corretamente.

Por exemplo, quando um projeto é compilado para depuração, um arquivo chamado "[projectName].deps.json" é gerado.
Neste arquivo no meu caso, eu vi isso como a primeira entrada para a biblioteca que eu estava referenciando:

"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 minhas suspeitas, executei o projeto e, no visual studio, abri debug->windows->modules e pude ver que o assembly que estava sendo carregado estava de fato incorreto. O código mencionado acima estava pegando apenas a primeira dependência da lista, que não funcionará em uma plataforma Windows.

Para minhas necessidades, consegui modificar a linha inicial 78 do LambdaAssemblyResolver.cs OnResolving para o seguinte:

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

Eu adicionei um filtro para extrair apenas versões de tempo de execução criadas para win 64 e posteriores, excluindo binários nativos.

Eu não enviei isso como um PR, pois é apenas 'bom o suficiente para mim' e meu caso específico, mas algo parecido em combinação com o sistema operacional e a detecção de plataforma permitiria o carregamento adequado da montagem.

Não tenho certeza se isso deve ser escalado para solicitação de recurso ou bug.

Além disso, se houver algo que eu possa fazer para contribuir com este projeto, por favor me avise.

Tendo um problema semelhante.

Estamos tentando adicionar Swagger: <PackageReference Include="Swashbuckle.AspNetCore" Version="4.0.1" />

Ele funciona no aplicativo asp.net implantado que está por trás do API Gateway.

Na ferramenta de teste, no entanto, ele lança essa exceção.

É muito fácil de reproduzir, modelo de projeto Serverless padrão, adicione o assembly acima, adicione as linhas services.AddSwaggerGen() e app.UseSwagger(); nos métodos ConfigureServices e Configure respectivamente.

Inicie o aplicativo com a ferramenta Mock Lambda. Faça qualquer solicitação usando o modelo do API Gateway da ferramenta. Ele lançará o FileNotFoundException

eu tenho o mesmo 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()

onde XYZ é .NET Standard 2.0 lib e projeto Lambda é Core 2.1

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

Oi, eu tenho o mesmo problema, alguma ajuda para resolver isso?

Mesmo problema hoje com System.Data.SqlClient.dll

Apenas curioso sobre isso .. mas eu executei o ProcMon e observei o caminho System.Data.SqlClient.dll - (o arquivo com o qual estou tendo problemas neste contexto) notei isso duas vezes, quando o dotnet-lambda-test-tool -2.1.exe está tentando fazer CreateFileMapping contra System.Data.SqlClient.dll ele obtém um resultado de FILE LOCKED WITH ONLY READERS. O que, após mais pesquisas, mostra que pode causar um erro "Não foi possível carregar o arquivo ou a montagem". Eu pensei que, ao reiniciar o Visual Studio 2019 como administrador, eu poderia fazer com que esse erro desaparecesse, mas não tive essa sorte. Suspeito que outras pessoas com esse problema também encontrarão esse problema com os assemblies nos Lambda que estão tentando depurar também. Espero que isso ajude alguém. Ainda estou procurando uma solução alternativa.

Ok, ok, ok.. Para mim, esse problema foi devido ao fato de eu ter que baixar a versão do pacote Nuget System.Data.SqlClient para 4.5.1. Por algum motivo, qualquer coisa mais alta produz o erro "Não foi possível carregar o arquivo ou o assembly" sobre o qual este tópico se refere. A versão 4.6 e superior me dão esse erro ao depurar localmente com a ferramenta de depuração Lambda.

Queria dar uma atualização de status. Atualmente, estou trabalhando na versão .NET Core 3.1 dessa ferramenta para o próximo runtime do .NET Core 3.1 Lambda. O trabalho para isso pode ser rastreado no mock-testtool-31 .

Nesta versão, estou usando o AssemblyDependencyResolver que foi adicionado no .NET Core 3.0 para carregar a função Lambda em um AssemblyLoadContext separado. Isso ajudará esses problemas se a função do Lambda usando uma versão diferente de um assembly foi carregada pela ferramenta de teste.

Como podemos testar 3.1?

Eu estava tendo o mesmo problema com meu projeto de modelo super simples,
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()
Também com Microsfot.Extensions.Configuration.Abstractions (último 3.1.3)

Depois de ler todos os comentários, uso a mesma solução que alguns de vocês. Eu tive que fazer o downgrade dos meus pacotes e dos referenciados por eles para uma versão inferior. Neste caso estou usando 2.1.

Isso é o que eu tenho agora para que minha ferramenta Mock possa funcionar.

Só para relembrar alguns fatos sobre o assunto.

• Projeto compila sem erros
• O projeto de teste é executado com sucesso
• A ferramenta de simulação não funciona quando o código que usa a dll é executado.

Esta é a linha que causa o erro no meu caso.
public MyFunction() : this(StartUp.Container.BuildServiceProvider()) {}
Este é o meu 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;
        }
    }
}

A versão 0.10.0 foi lançada hoje para .NET Core 2.1 e .NET Core 3.1, que agora carrega o código Lambda em um AssemblyLoadContext separado. Acredito que isso resolverá muitos dos problemas relatados aqui. Vou encerrar esta questão, pois ela é antiga e acredito que há várias questões separadas. Depois de usar a nova versão, se ainda houver um problema, abra um problema separado para facilitar o rastreamento.

Obrigado @normj e parabéns, vou testar

@normj
Ei. Eu tive os mesmos problemas 6 dias atrás. Eu tentei cobrir todas as informações que eu tinha no último post deste tópico. Eu não acho que este problema está resolvido ainda até que tenhamos provas.

Você testou com 3.1?

@Edulopez Você já experimentou a última versão que saiu ontem? Se o problema ainda existir, crie um problema separado com seu repositório. Eu apenas senti que este tópico ficou pesado e suspeito que muitos problemas relatados serão corrigidos com a nova versão.