aws-lambda-dotnet: Nuget dependency is throwing System.IO.FileNotFoundException

I have the same issue with the Google.Apis.Auth dependency. It works fine when deployed to AWS but when I try to run it locally with the test tool, I get this error. I’m using .NET Core 2.1 and test tool 0.9.2.

System.IO.FileLoadException: Could not load file or assembly ‘Google.Apis.Auth, Version=1.35.1.0, Culture=neutral, PublicKeyToken=4b01fa6e34db77ab’. An operation is not legal in the current state.

I got the same issue

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

where XYZ is .NET Standard 2.0 lib and Lambda project is Core 2.1

I was having the same issue with my super simple template project, 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() Also with Microsfot.Extensions.Configuration.Abstractions (latest 3.1.3)

After reading all the comments I use the same solution as some of you. I had to downgrade my packages and the ones referenced by them to a lower version. In this case I’m using 2.1.

This is what I have now so my Mock tool can work.

Just to remind some of the facts about the issue.

• Project compiles with no errors
• Test project runs successfully
• Mock tool does not work when code that use the dll is executed.

This is the line that cause the error in my case. public MyFunction() : this(StartUp.Container.BuildServiceProvider()) {} This is my 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;
        }
    }
}

Wanted to give a status update. I’m currently working on the .NET Core 3.1 version of this tool for the upcoming .NET Core 3.1 Lambda runtime. The work for that can be tracked in the mock-testtool-31.

In this version I’m using the AssemblyDependencyResolver which was added in .NET Core 3.0 to load the Lambda function in a separate AssemblyLoadContext. That will help these issues if the Lambda function using a different version of an assembly then was loaded by the test tool.

The Problem:

I have a similar issue, but with a different library. I have a netcore2.1 lambda project that references Microsoft.EntityFrameworkCore 2.2.3 and Microsoft.EntityFrameworkCore.Sqlite 2.2.3. When running in visual studio with the Mock Lambda Test Tool, the following exception is thrown:

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)

I have confirmed that this lambda function can be deployed and run successfully in the real AWS cloud based Lambda environment.

See the small reproduction project attached

The Source:

I cloned the aws-lambda-dotnet repo and ran the test tool. I created new unit test to invoke the tool and step into the code. The test tool throws the exception during the Amazon.Lambda.TestTool.Runtime::LambdaAssemblyResolver::OnResolving method. This method cannot resolve AssemblyName = Microsoft.Data.Sqlite and will return null. This method is the last method called before the LoadContext has to call a System.IO.FileNotFoundException if the assembly is not resolved.

---

The solution posted in another issue works. In that issue, the author simply downgraded to a 2.1.* version. If we downgrade to 2.1.8 for both ef core references, the test tool starts working again. However this is not an option for me. I’m trying to take advantage of new features in ef core 2.2.*. IMO the tool should be able to load assemblies that are also supported in lambda.

This open issue in the corefx repo may give hints into the underlying issue.

I would explore further, but I don’t have the time. Any ideas?

AWSLambda_NetCore21-EfCore22Test.zip

Version 0.10.0 was released today for both .NET Core 2.1 and .NET Core 3.1 which now loads the Lambda code in a separate AssemblyLoadContext. I believe that will fix a lot of the reported issues here. I’m going to close this issue as it is old and I believe there are several separate issues. After using the new version if there is still an issue please open a separate issue to make it easier to track.

Ok, ok, ok… For me this issue was due to the fact that I had to lower the version of the System.Data.SqlClient Nuget package to 4.5.1. For some reason, anything higher produces that “Could not load file or assembly” error that this thread is about. The version 4.6 and above give me that error when debugging locally with the Lambda debugging tool.

I ran into this issue and believe I may have found the cause for “An operation is not legal in the current state.”. Please excuse the poor formatting in the response below.

Tools\LambdaTestTool\Amazon.Lambda.TestTool\Runtime\LambdaAssemblyResolver.cs OnResolving Line 79 and more specifically Line 93:

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

The issue here, is that if an assembly contains multiple runtimes, it will only select the first in the list. In some cases, this is a unix runtime which is not compatible with a windows machine which in my case, is the operating system I am using for development.

This will not cause an issue when deployed because publishing the project renders the dependencies properly.

For example, when a project is compiled for debug, a file named “[projectName].deps.json” is generated. In this file in my case, I saw this as the first entry for the library I was referencing:

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

To verify my suspicions I ran the project, and in visual studio opened debug->windows->modules and could see that the assembly being loaded was in fact incorrect. The code mentioned above was taking only the first dependency in the list, which will not work on a windows platform.

For my needs, I was able to modify LambdaAssemblyResolver.cs OnResolving starting line 78 to the following:

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

I added a filter to pull only runtime versions that are built for win 64 and later, exclude native binaries.

I did not submit this as a PR since it is only ‘good enough for me’ and my specific case, but something like it in combination with operating system and platform detection would allow for proper assembly loading.

Not sure if this should be escalated to feature request or Bug.

Also if there is anything I can do to contribute to this project, please let me know.

@AngelVenchev Could you try changing version from 2.2 to 2.1? This worked for me for a similar issue. May have to do with Lambda not supporting .Net Core 2.2

My previous comment, which I’ve edited, was wrong. Latest problem was just PEBKAC. The LibPhoneNumber assembly was found just fine.

I pushed out version 0.9.2 that has a change to how dependencies are searched for. With this change I was able to execute a lambda function with this tool that used libphonenumber.

If you are using Visual Studio and the AWS Toolkit for Visual Studio the update to 0.9.2 should happen automatically the next time you open your solution assuming you are online.