kubeless
kubeless copied to clipboard
Kubeless should load function in separate AssemblyLoadContext
Is this a BUG REPORT or FEATURE REQUEST?: Bug report What happened: I cannot load Newtonsoft JSON into .Net Kubeless function since it will throw error:
System.IO.FileLoadException: Could not load file or assembly 'Newtonsoft.Json, Version=12.0.0.0
What you expected to happen: It is expected to work How to reproduce it (as minimally and precisely as possible): Create a function with Newtonsoft.Json 12.0.3 as dependency.
Anything else we need to know?:
Simular problem was with Amazon Lambda:
https://github.com/aws/aws-lambda-dotnet/issues/450 https://github.com/aws/aws-lambda-dotnet/issues/453
cc/ @allantargino
Hi @vasicvuk,
The runtime is already shipped with Newtonsoft.JSON 11.0.2. At any class you can just import it (using Newtonsoft.Json;
) without explicit adding it as a dependency on your .csproj
.
The error you are getting is because by default the runtime won't load duplicated dependencies. Does 11.0.2 satisfy your needs?
@allantargino This issue is about having separate Assembly Load Context so that this issue won't happen for any other library.
Anyway we would like to always have up to date libraries in case of security issues.
I've just come across this same issue, or at least I presume it's the same issue. My pod crashes on startup due to failing to load an assembly, the only assembly in my csproj (aside from the Kubeless.Functions one) is Newtonsoft.Json.
Removing the --dependencies foo.csproj
argument results in a compilation error as the Newtonsoft namespace cannot be found. I presumed that as Newtonsoft.Json 11.0.2 was already shipped with the runtime, and it was my only dependency that I could remove the csproj from the deployment entirely, is this not correct?
Also, I agree with @vasicvuk that not being able to ship functions with the latest version of libraries is far from ideal, especially as we're looking at porting some code over to functions that already makes use of Newtonsoft.Json 12.0.2 and downgrading is not really an option.
Hi @garethpixelpin and @vasicvuk,
I see your point and makes sense to have an isolated environment for dependencies. We would appreciate any contributions to the .NET Core runtime in order to introduce this behavior (please check the source code at https://github.com/kubeless/runtimes/tree/master/stable/dotnetcore/src).
As soon as this refactor is merged https://github.com/kubeless/runtimes/pull/58, we can accept that enhancement.
Thanks!