Serverless-offline: .NET Core Support

[petermorlion]

I notice there is Docker support and that it should, in theory, allow .NET Core support (mentioned in #845).

I'm wondering if this has been tested and/or should work out of the box or if there is more work to be done. Because the docs don't mention .NET Core.

If there is more work to be done, I'd be glad to help. I've tried running the aws-csharp example (with a slightly modified serverless-offline plugin to allow dotnetcore runtime), but I get an error:

AWSLambda.Internal.Bootstrap.LambdaValidationException: Could not find the specified handler assembly with the file name 'CsharpHandlers, Culture=neutral, PublicKey
Token=null'. The assembly should be located in the root of your uploaded .zip file.

And indeed, there is no zip file in my .serverless folder. Though I have the same issue when I run serverless invoke local -f hello.

So my question is this: do you want me to investigate this so we can confirm serverless-offline supports .NET Core? Or do you already know it does (and then the issue I'm having is something I should fix myself)?

[frozenbonito]

I think artifact support is required for .NET core support, but it is ommited in initial docker support (mentioned in https://github.com/dherault/serverless-offline/pull/845#issuecomment-566592798, https://github.com/dherault/serverless-offline/pull/845#issuecomment-567148847).
ref: https://serverless.com/framework/docs/providers/aws/guide/packaging#artifact

I would like to create a new PR about artifact support in the near future.

[dnalborczyk]

@petermorlion current ruby and python support is pretty much based on the serverless implementation: https://github.com/serverless/serverless/blob/master/lib/plugins/aws/invokeLocal/index.js I would imagine .net support could be implemented similar to java.

I suppose the docker support more or less as well @frozenbonito ? is that the way serverless supports .net?

[frozenbonito]

Local artifact is now supported!
I hope to someone who familiar with .NET will add .NET runtime test.

1. edit this file to enable dotnetcore runtimes
2. add dotnetcore test to here (please refer to other runtime tests, nodejs, python, ruby and go)

[petermorlion]

I'm working on it. Having some issues which I hope to resolve. I'll keep you posted.

[alex-vance]

@petermorlion if you need any help, please let me know. I've been working with .net core for a while and more than happy to assist.

[petermorlion]

@alex-vance That would be great. I have experience with serverless and .NET Core, but the combination proves to be tricky for me.

In this fork (on the dotnet-support branch), I've reached a point the code detects .NET Core 3.1 (see detectDotnetcore.js and npmInstall.js), but I don't seem to enter the DotnetcoreRunner.js.

And after that, I'll still have the issue of running the lambda handler file.

I struggled with Docker for a while and then tried to run it directly on my system. Apparently, my struggle had nothing to do with Docker. It was the same issue as I'm having now. But as .NET Core is cross-platform, it seemed OK to run it directly instead of in a container.

[alex-vance]

@petermorlion I've started taking a look at this (forked from yours) and i can see a few things that will be complicated:

1. Like the other languages/runtimes, we will probably need some sort of invoker/wrapper that can invoke the assembly artifact that's created for .net core lambdas.
2. The invoker/wrapper will need to be created for each supported dotnetcore runtime.

My main question is: should we pre-compile the invoker/wrapper for each runtime OR compile on the fly each time the lambda executes? I would assume the first idea would absolutely be more performant, but it means that anytime the invoker/wrapper is changed (for each dotnetcore runtime) we would need to insure that the compiled binaries are updated as well. This just seems to add some complexity that might not be preferred.

I've gotten as far as being able to execute sls offline and it attempt to run the lambda artifact. The problem is that because no Main method is found, it's assumed to be a library and thus cannot be run directly. I think the biggest hurtle left is going to be the invoker/wrapper.

[petermorlion]

Cool! Glad you made more progress than I did. I believe compiling each time the lambda executes would be the most flexible and user-friendly solution.

[alex-vance]

@petermorlion If you'd like, i started a PR against your fork. Let's take the discussion there to stay close to the code if you don't mind. We can update this issue as soon as we have some progress to report back.

[alex-vance]

@petermorlion I went ahead and created the PR #979 for this. Feel free to comment on there with feedback!

[cmonteiro128]

Any progress on this?

[petermorlion]

@cmonteiro128 Well, I couldn't get the tests to run green. I'm a little out of time currently. Don't know what @alex-vance 's situation is?

[drewsb]

Any update on this?