Aws-lambda-dotnet: Exception when trying to use Npgsql to connect to an RDS instance

[jakejscott]

Was using Npgsql 3.1.9

START RequestId: 147aefc2-c10f-11e6-b24b-6daefcf72be1 Version: $LATEST Exception System.TypeInitializationException: The type initializer for 'Npgsql.TypeHandlerRegistry' threw an exception. ---> System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information. at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module) at System.Reflection.Assembly.GetTypes() at Npgsql.TypeHandlerRegistry..cctor() --- End of inner exception stack trace --- at Npgsql.TypeHandlerRegistry.Setup(NpgsqlConnector connector, NpgsqlTimeout timeout) at Npgsql.NpgsqlConnector.Open(NpgsqlTimeout timeout) at Npgsql.ConnectorPool.Allocate(NpgsqlConnection conn, NpgsqlTimeout timeout) at Npgsql.NpgsqlConnection.OpenInternal() at Seaside.Api.HelloWorld.Functions.<GetAsync>d__0.MoveNext() END RequestId: 147aefc2-c10f-11e6-b24b-6daefcf72be1 REPORT RequestId: 147aefc2-c10f-11e6-b24b-6daefcf72be1 Duration: 96.22 ms Billed Duration: 100 ms Memory Size: 256 MB Max Memory Used: 31 MB

[normj]

Resolving native dependencies is something we are working on to get better. As a work around till then you can add in the aws-lambda-tools-defaults.json file the "additional-files" property which will force the native resolution. Once I did this I was able to connect to a postgresql database.

  ...
  "function-handler": "NpgsqlTest::NpgsqlTest.Function::FunctionHandler",

  "additional-files": [
    "runtimes/linux/lib/netstandard1.3/System.Net.NetworkInformation.dll"
  ]
}

[jakejscott]

Nice one Norm 👍

[siegesmund]

I'm having the same problem, but with .Net core on a Mac. Is there an equivalent to "additional-files" when not using visual studio or aws-lambda-tools?

[normj]

If you are using the Amazon.Lambda.Tools NuGet package to deploy then the when you execute dotnet lambda deploy-function it will read the aws-lambda-tools-defaults.json file just like Visual Studio does including the additional-files section.

We wanted to make sure that all the deployment features in Visual Studio were available through the dotnet CLI to support users on Macs.

[BrendanGrant]

This answer saved me much additional pain... however it's worth noting that if you are not using VS to build your package/upload but instead the regular coreclr tools (ie "dotnet publish"), any settings in aws-lambda-tools-defaults.json are ignored, so manually copying this file over to the root of the package dir is required.

[normj]

I recommend instead of using dotnet publish use either dotnet lambda package. This will do the same packaging that we do in Visual Studio but from the dotnet CLI. You can see the full list of commands we have added to the dotnet CLI via the NuGet package Amazon.Lambda.Tools by executing dotnet lambda help