Aws-lambda-dotnet: Exception when trying to use Npgsql to connect to an RDS instance
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
jakejscott
All 6 comments
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"
]
}
normj
on 13 Dec 2016
Nice one Norm 👍
jakejscott
on 13 Dec 2016
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?
siegesmund
on 22 Dec 2016
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.
normj
on 23 Dec 2016
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.
BrendanGrant
on 1 Feb 2017
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
normj
on 1 Feb 2017
Related issues
rv-dtomaz
·
6Comments
ibuchan72390
·
7Comments
pandaedward
·
6Comments
briancullinan
·
7Comments
ShaneGMamet
·
3Comments
Most helpful comment
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.