'AWS Lambda, .Net Core, & MySql: Could not load file or assembly 'System.Diagnostics.TraceSource, Version=4.0.0.0

I am building out lambda microservices that access data via MySql in RDS. My local unit tests work fine but when I publish to AWS, I get the following error:

    {
  "TypeName": "MySql.Data.MySqlClient.MySqlTrace",
  "Message": "The type initializer for 'MySql.Data.MySqlClient.MySqlTrace' threw an exception.",
  "Data": {},
  "InnerException": {
    "Message": "Could not load file or assembly 'System.Diagnostics.TraceSource, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.\n",
    "FileName": "System.Diagnostics.TraceSource, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a",
    "Data": {},
    "InnerException": {
      "Message": "'System.Diagnostics.TraceSource, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' not found in the deployment package or in the installed Microsoft.NETCore.App.",
      "FileName": null,
      "Data": {},
      "InnerException": null,
      "StackTrace": "   at AWSLambda.Internal.Bootstrap.LambdaAssemblyLoadContext.Load(AssemblyName assemblyName)\n   at System.Runtime.Loader.AssemblyLoadContext.ResolveUsingLoad(AssemblyName assemblyName)\n   at System.Runtime.Loader.AssemblyLoadContext.Resolve(IntPtr gchManagedAssemblyLoadContext, AssemblyName assemblyName)",
      "HelpLink": null,
      "Source": "Bootstrap",
      "HResult": -2147024894
    },
    "StackTrace": null,
    "HelpLink": null,
    "Source": null,
    "HResult": -2147024894
  },
  "StackTrace": "   at MySql.Data.MySqlClient.MySqlTrace.LogError(Int32 id, String msg)\n   at MySql.Data.MySqlClient.MySqlPool.TryToGetDriver()\n   at MySql.Data.MySqlClient.MySqlPool.GetConnection()\n   at MySql.Data.MySqlClient.MySqlConnection.Open()\n   at HealthStats.Functions.GetLocationTypes(APIGatewayProxyRequest request, ILambdaContext context)",
  "HelpLink": null,
  "Source": "MySql.Data",
  "HResult": -2146233036
}

Here is my project.json file. I have tried to add the System.Diagnostics.TraceSource library as a standard project dependency (not shown) and as a framework dependency (shown below). My thinking was maybe during publish it was not adding the assembly because I didn't directly use TraceSource in my code. However, neither attempt resolved the issue:

{
  "version": "1.0.0-*",
  "buildOptions": {
    "emitEntryPoint": false
  },

  "dependencies": {
    "Amazon.Lambda.APIGatewayEvents": "1.0.1",
    "Amazon.Lambda.Core": "1.0.0",
    "Amazon.Lambda.Serialization.Json": "1.0.1",
    "Amazon.Lambda.Tools": {
      "type": "build",
      "version": "1.1.0-preview1"
    },
    "Microsoft.NETCore.App": {
      "type": "platform",
      "version": "1.0.0"
    },
    "MySql.Data": "7.0.6-IR31"
  },

  "tools": {
    "Amazon.Lambda.Tools" : "1.1.0-preview1"
  },

  "frameworks": {
    "netcoreapp1.0": {
      "dependencies": {
        "System.Diagnostics.TraceSource": "4.0.0"
      },
      "imports": [
        "dnxcore50",
        "portable-net45+win8"
      ]
    }
  }
}

Any ideas?



Solution 1:[1]

I was seeing a similar problem in the lambda results:

The type initializer for 'MySql.Data.MySqlClient.MySqlTrace' threw an exception.: TypeInitializationException at MySql.Data.MySqlClient.MySqlTrace.LogError(Int32 id, String msg) at MySql.Data.MySqlClient.MySqlPool.TryToGetDriver() at MySql.Data.MySqlClient.MySqlPool.GetConnection() at MySql.Data.MySqlClient.MySqlConnection.Open() at AWSLambda2.Function.FunctionHandler(SNSEvent input, ILambdaContext context) at lambda_method(Closure , Stream , Stream , ContextInfo )

'System.Diagnostics.TraceSource, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' not found in the deployment package or in the installed Microsoft.NETCore.App.: FileNotFoundException at AWSLambda.Internal.Bootstrap.LambdaAssemblyLoadContext.Load(AssemblyName assemblyName) at System.Runtime.Loader.AssemblyLoadContext.ResolveUsingLoad(AssemblyName assemblyName) at System.Runtime.Loader.AssemblyLoadContext.Resolve(IntPtr gchManagedAssemblyLoadContext, AssemblyName assemblyName)

What worked for me was manually publishing the project using dotnet publish and then within that published folder navigating to .\publish\runtimes\unix\lib\netstandard1.3 and copying the dlls that were published there into .\publish. Once those were in that folder, I zipped up the contents of the publish folder, excluding the runtimes sub-folder, and uploaded that to lambda.

My working theory for why this happens is because dotnet publish is publishing as if an intelligent system is using the results, however I think the lambda is loading the assembly into another context which doesn't know about looking in sub-folders for dependencies.

Solution 2:[2]

The simplest solution is to edit the project.json file. To add a prepublish event

"scripts": { "prepublish": [ "xcopy ./bin/Release/netcoreapp1.0/publish/runtimes/unix/libnetstandard1.3/System.Diagnostics.TraceSource.dll ./bin/Release/" ], "postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ] } This causes the reference to be copied before the AWS Publishing Wizard copies it.

Regards

Aldo Flores

Solution 3:[3]

Similar to @alduar but I think it is more appropriate to put it in postpublish, since the dll will not be there on first build. And I think it should be copied to the publish directory. Note, these file paths are for windows.

    "scripts": {
       "postpublish": [ "xcopy bin\\Release\\netcoreapp1.0\\publish\\runtimes\\unix\\lib\\netstandard1.3\\System.Diagnostics.TraceSource.dll bin\\Release\\netcoreapp1.0\\publish\\" ]
    },

Solution 4:[4]

I had the same issue after running the following command.

dotnet publish src\Lambda.csproj -c Release

At first I fixed it by copying the files from runtimes\unix\lib\netstandard1.3 like Jon Peterson suggested.

I found a solution which seems cleaner though. Now I just run the following.

dotnet publish src\Lambda.csproj -c Release -r linux

This will create a publish folder which contains all the correct files.

Solution 5:[5]

I have similar problem, in my case helped to remove from .csproj file line

<PublishReadyToRun>true</PublishReadyToRun> 

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Jon Peterson
Solution 2 alduar
Solution 3 dohmoose
Solution 4 andreas
Solution 5 Wieslaw Olborski