.NET Core 3.1 (LTS) has been released

[raRaRa]

.NET Core 3.1 (LTS) has been released - https://devblogs.microsoft.com/dotnet/announcing-net-core-3-1/

Any plans to support it any time soon? Thanks.

[normj]

Its an LTS and will be supported. It will just take sometime to get .NET Core 3.1 ready for Lambda and deployed out.

[hounddog22030]

Its an LTS and will be supported. It will just take a sometime to get .NET Core 3.1 ready for Lambda and deployed out.

If there's anything I can do to help out, please let me know.

[ckuetbach]

Will there be a speedup for the cold start time?

.NET Core 3.1 has some features like AOT compile

• PublishReadyToRun
• PublishTrimmed

[beeradmoore]

@normj should people subscribe to this issue for updates or is there another .NET Core 3.1 issue which we should follow for progress?

[normj]

We can use this issue to track updates. Unfortunately I probably won't be able to provide much of status updates till it is out.

[daseintheworld]

Will there be a speedup for the cold start time?

.NET Core 3.1 has some features like AOT compile

• PublishReadyToRun
• PublishTrimmed

In case the answer is yes for the comment, will it be possible to run and test the 'compiled lambda' from a local environment? I would eagerly set a linux environment for it :)

[rati-dzidziguri]

Any update here?

[beeradmoore]

@rati-dzidziguri

As above from @normj

We can use this issue to track updates. Unfortunately I probably won't be able to provide much of status updates till it is out.

[rati-dzidziguri]

@beeradmoore
My question was about ETA. That would be helpful to know ETA for this as we could prepare accordingly.

[Kralizek]

@rati-dzidziguri Amazon seldom discloses their ETA when it comes to releases.

[normj]

@rati-dzidziguri I understand and appreciate you wanting an ETA so you can plan accordingly. In reality it is for that reason we generally don't give an ETA because we try really hard to not make promises that we are not 100% sure we can keep. I would hate to give you an ETA and you make your roadmap based on that and we then me miss that ETA you expected throwing all of your plans into disarray.

For now if you really are needing .NET Core 3.1 features then i suggest using .NET Core 3.1 as a Lambda Custom Runtime which is explained here (except change references from .NET Core 3.0 to .NET Core 3.1). Then when the native .NET Core 3.1 support comes along you will have a very simple migration of changing a few settings on your Lambda function.

[daseintheworld]

@normj One reason made me decide that I can't use the custom runtime feature with the 'LambdaEntry' class is the 'monolithic architectural' aspect of the implementation approach. Every API request comes through the only one entry lambda and 'distributed' to controllers of the ASP .net project is what the custom runtime structure intended, which is definitely convenient but includes structural downside for cases like I want. I want every command/query request to become lambda each. Since then I can get a scalabillity on managing deployment packages that I can split some functions and manage codes anytime I want.
This is why I am waiting for the official runtime to be supported that I can construct a bundle of 'single purposed lambdas' using SAM written in a template with 'runtime : .netcore 3.1' config.

Please give me an advice if I am going wrong :)

[martincostello]

You can definitely achieve multiple lambda functions from one code base using the Lambda Bootstrapper and the custom runtime feature.

I have a suite of 16 lambdas that are deployed from one application, rather than a “monolith”.

This is achieved by using the _handler environment variable to pick the method to use at runtime, rather than the hard-coded one-to-one mapping shown in the blog post’s sample code.

I think of it as a console app which receives a switch that tells it what action to “become” when started up.