.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.

[daseintheworld]

@martincostello Thank you for the kind suggestion! I can figure out what your case may look like. You might have placed the switch logic in the Main or Startup class that it can be determined it's functionality on the first stage of the runtime. And it can solve the 'only-monolithic' issue, of course. Very clever approach :)

But still, there is one (if not many) consideration I have to think of, especially when I imagine working as a team. Using custom runtime and determining the 'functional identity' on startup will get rid of the possibility of SAM. For easy example for us, API gateway cannot be defined while deploying a lambda, which means we have to manually generate one for it. I know I'm exaggerating here because we can make something SAM-like configuration using the bootstrap script as aws tutorial explained. But it won't completely satisfy us since it is using a linux script which means (1) it can be embarrassing for new-comers, and sometimes it will become a learning curve. (2) it will discard the benefit of the serverless template's expressiveness because it is literally a script, not a document.

I think the serverless template works as a semi-document of what the server looks like and how it works, which will not only be shared within a development team but even with some insightful non-technicians. and SAM is a well-defined concept that in the near future one's abstract representations of an application will make it possible to be reused by another team using totally different languages and platforms. These aspects still undeniably motivate me to stick to use 'the serverless template' feature.

[CumpsD]

Some nice dates ahead to release this, 25 dec, 1 january come to mind ;)

[normj]

Happy holidays all, I wish I could give you all .NET Core 3.1 Lambda runtime for Christmas but I think 2020 is going to be an exciting your for .NET and AWS.

[raRaRa]

Happy holidays all, I wish I could give you all .NET Core 3.1 Lambda runtime for Christmas but I think 2020 is going to be an exciting your for .NET and AWS.

No worries, enjoy the holidays! Can't wait to see what you have for us in 2020! :)

[neetika123]

waiting for lambda native support on .NetCore3.1

[abukres]

There's a disk size limit to lambda functions. I think it's 250 megs and when using the custom runtime, we have to send all of asp.net core assemblies along with our app. I reached that limit when AWS was unzipping my zip package. I had to do some cleanup to reduce the space used by my app. When native support comes out, we don't have to package our app with .core's assemblies.

[erikdac]

Is there any estimate on when we can expect this to be released?

We are waiting to upgrade to .Net core 3.1 until there is native support for it.

[abukres]

Is there any estimate on when we can expect this to be released?

We are waiting to upgrade to .Net core 3.1 until there is native support for it.

If you go back and read the replies, you'll read from normj that they won't give any estimates.

[clearwaterstream]

If you go back and read the replies, you'll read from normj that they won't give any estimates.

Mmmm normally -- yes. But if enough folks show up with pitch forks then maybe a hint of a release date will be given out to quell the unrest :grin:

[VagyokC4]

I remember a while back when AWS spent a long time preparing the 2.1 native images. They said something to the effect that they redesigned the process to make deploying future versions easier and faster to stand-up. Enter NetCore 3.1 and almost two months later and it's still not available :(

You know Azure had this 3.1 image available Day 1. I'm beginning to see why the US Government choose Azure as their cloud provider for JEDI.

We just got the green light from our stakeholders to start targeting Azure as our primary provider leaving AWS as the backup. With silly delays like this, I'm sure we are not the only ones.

[Rajaniyer]

I remember a while back when AWS spent a long time preparing the 2.1 native images. They said something to the effect that they redesigned the process to make deploying future versions easier and faster to stand-up. Enter NetCore 3.1 and almost two months later and it's still not available :(

You know Azure had this 3.1 image available Day 1. I'm beginning to see why the US Government choose Azure as their cloud provider for JEDI.

We just got the green light from our stakeholders to start targeting Azure as our primary provider leaving AWS as the backup. With silly delays like this, I'm sure we are not the only ones.

I agree with you. My org doesnt allow custom runtime and we are kind of stuck with 2.1. When it comes to EF & Postgres along with spatial operations, it is too much pain. We have been waiting for this to be done. Too bad that it is not done yet.

[abukres]

I remember a while back when AWS spent a long time preparing the 2.1 native images. They said something to the effect that they redesigned the process to make deploying future versions easier and faster to stand-up. Enter NetCore 3.1 and almost two months later and it's still not available :(

You know Azure had this 3.1 image available Day 1. I'm beginning to see why the US Government choose Azure as their cloud provider for JEDI.

We just got the green light from our stakeholders to start targeting Azure as our primary provider leaving AWS as the backup. With silly delays like this, I'm sure we are not the only ones.

Does JEDI use .NET Core to make the assumption that's why the government went with Azure?

[assyadh]

Hi everyone,

I am actively working on bringing the support for .NET Core 3.1 in Lambda. It takes some time because a lot of work was done by Microsoft in how they build the runtime. I am working on incorporating these changes to bring you a native runtime.

[JamesQMurphy]

@assyadh Thank you! I do not believe the delays are "silly"; in fact, I would rather wait for a solid working version. I love that AWS Lambda supports .NET Core and I appreciate that you are continuing to support it, as promised.

[Kralizek]

I don't understand the urge. It's not that we don't have a LTS environment right now.

Obviously we want to use the new toys but the .NET team at AWS has only a fixed amount of resources and they can't do everything at once.

Besides, I am not longing for the need of rushing and updating all the functions' runtime in fear of being out of servicing terms.

[damianh]

Good for you @Kralizek but your situation is yours and doesn't represent others . It's not really "new toys" now is it. .NET Core 3.x (and ASP.NET Core) has significant improvements over 2.x in a variety of ways and early adopters are keen to adopt and leverage. As @JamesQMurphy says, we'd also prefer the release is solid.

I look forward to seeing your work @assyadh.

[hounddog22030]

"I don't understand the urge."

We can't use shared .NET Core 3.1 in a .NET Core 2.1 lambda function, in fact we can't even use shared .NET Core 2.2 code in a .NET Core 2.1 lambda function, so we recently had to begrudgingly downgrade our shared components to .NET Core 2.1 to get them to be supported in the function.

Can your shared components be compiled in netstandard20? Then you can share them in netcore2&3

[martincostello]

Whilst this thread is specific to .NET 3.1, I’m sure this exact conversation will be played out again when .NET 5 arrives (or 6 if that’s going to be the next LTS).

While some specific examples have been cited where it isn’t possible (e.g. code ZIP file too big, company policy), in general if you want to use the “latest and greatest“ .NET Core going forwards, you can do this with a little refactoring and the custom runtime support package.

At this time we just happen to be at a point where the latest release also happens to be an LTS release, which seems to be making the need to have it “ASAP” from Amazon seem a lot more “urgent” that it was with, say, having built-in 2.2 or 3.0 support.

Ultimately there’s a trade-off to be made between new features being usable on Lambda vs development effort needed to be put in with PaaS solutions.

.NET Core 3.1 wasn’t even available on Microsoft’s Azure App Service for 2-3 weeks after it was released.

If you generally like to be on the “bleeding edge” ASAP, taking a small investment in using the custom runtime support in the short term will unlock you to potentially run any future version of .NET Core in Lambda on your own timescales. Of course the trade off here amongst other things is larger packages, slightly more code, and the need to do your own patching.

With everything, there’s a balance and a trade-off, and for built-in support there’s realistically always going to be a lag for availability because software takes time.

With major releases of .NET being in November time going forwards, the Christmas/Holiday period is probably always going to have an effect on how long making these things available built in will take in terms of the Lambda team’s time and available capacity.

[normj]

Just adding my thoughts. I do understand how this release is very important and I appreciate you telling us. I use that feedback to push the urgency on our side. As @martincostello mentioned the timing of when .NET Core 3.1 came out was not great due to the holidays but also during reInvent.

I was the guy that mentioned in the past for 2.1 that I hopped the automation we put in place would speed up the future release. The automation that @assyadh put in has really helped us but unfortunately as software goes things have changed a lot since we did .NET Core 2.1. Part of it is how MS builds .NET Core and the other part is how the Lambda service works with the move to Amazon Linux 2.

So please believe me that .NET Core 3.1 is @assyadh, myself and many others highest priority to get done.

[mungojam]

Just to check, does the work to incorporate it start once Microsoft release pre-releases rather than waiting for the final release? That would presumably reduce the impact of Christmas and allow it to be delivered sooner once the final release comes out as it would just need testing.

[morquan]

I use that feedback to push the urgency on our side

Thank you for this @normj. Here's my $0.02, in hopes it also helps your evangelism.

As @martincostello mentioned the timing of when .NET Core 3.1 came out was not great due to the holidays but also during reInvent.

As @mungojam alluded to, .NET Core 3.1 was available in preview form starting Oct 15th, over a month before release. Also, it's basically a bug fix release of 3.0 - I don't know your tools but I would imagine exploratory work could have started using 3.0, which was released September 23rd and in preview all year. It's worth noting that 3.1 was given an estimated release date in the 3.0 release announcement.

.NET Core 3.1 wasn’t even available on Microsoft’s Azure App Service for 2-3 weeks after it was released.

.NET Core 3.1 was available on Azure Functions October 17th, two days after Preview 1 was released.

You can say what you will about any company's need to have 3.1 right away, whether it's "bleeding edge", custom runtime options, and so on, but this is really part of a bigger picture about how seriously AWS wants to support us .NET customers. If AWS - not Norm's team, but AWS overall - had made it a priority, I have to think they could have been out in front of this, making sure they were competing with Azure.

Personally, I really value having options among cloud offerings that I can choose based on merit rather than corporate dogma, and I would love to see AWS take the next step in improving .NET support.

Thanks @normj, @assyadh, and any others working on this for your efforts.

[clearwaterstream]

It's possible the .NET team at AWS very well started their journey of prepping for .NET 3.1 LTS upon release of 3.0 preview. Thing is, AWS tends to be tight lipped about what they are working on behind the curtains. This lack of transparency breeds suppositions. I think it would not hurt to have some sort of a roadmap, even if it's tentative and the dates are subject to change, etc.

[abukres]

I think the issue is that the AWS team doesn't want to put out any kind of ETA and therefore developers are put in the dark. @normj says that's because he doesn't want anyone or any company make future plans based on those ETAs. Isn't the general understanding that an ETA is just an estimate and no company should make serious plans based on another company's estimates and even if they did, the company can't blame AWS or be angry at it for missing an ETA?

An ETA also is not a specific day. It can be a month. A quarter. And we should be OK with any ETA and OK if it got missed.

[petarrepac]

Looking at https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html it seems AWS deprecates the runtime soon after the end-of-life of that runtime version.

Because .NET Core LTS versions are supported for 3 years we are already "spending the time we can use .NET Core 3.1 lambdas". Therefore, I understand people are inpatient to get .NET core 3.1 on lambdas. BTW, I would also prefer rock solid release then something rushed.

I'm assuming it will be available in next month or two, but some commitment from AWS, even if very conservative could be beneficial for teams to plan their operations.

Another thing is that in this time of OSS: can .NET community help? We are talking on github after all. Is this "built-in" runtime some closed code?

Also, it would be a KILLER feature if deployment process had a switch to do ReadyToRun and other AOT compiling features so cold-start times go seriously down. That would make .NET Core VERY attractive on AWS Lambda, IMO.

@normj and team: thank you for making .NET core great on AWS

[VagyokC4]

Just adding my thoughts. I do understand how this release is very important and I appreciate you telling us. I use that feedback to push the urgency on our side.

Please use this post to push urgency on your side. With that in mind, here are my two pennies.

Just to check, does the work to incorporate it start once Microsoft release pre-releases rather than waiting for the final release?

Question: Will we get an honest answer to this question?

It feels like the answer is self-evident. It feels like the priority for .NET is "hobby-level" and not "enterprise-level" as it should be.

I've heard somewhere that 1) the whole Net Core stuff has been made open-source, and 2) there exist some early adopter programs that allow you to "hit the ground running" upon actual release. (see Google for details.)

I'm being funny here, but the truth is, everyone who follows .NET knows this, so it adds to the self-evidence in which I speak.

Honestly, After the 2.1 delays in the release, I was hopeful that the changes made back then meant that this time around (3.1) we would have support for the new framework no more than two weeks out from actual release. I mean within hours of release would be ideal, but giving some room for final touches/polish, within two weeks feels about right.

But here we are almost two months out and it just feels "hobby-level-ish".

@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.

This is "hobby-level" thinking, as @abukres so elegantly states:

I think the issue is that the AWS team doesn't want to put out any kind of ETA and therefore developers are put in the dark. @normj says that's because he doesn't want anyone or any company make future plans based on those ETAs. Isn't the general understanding that an ETA is just an estimate and no company should make serious plans based on another company's estimates and even if they did, the company can't blame AWS or be angry at it for missing an ETA?

An ETA also is not a specific day. It can be a month. A quarter. And we should be OK with any ETA and OK if it got missed.

I think the fact AWS lost the JEDI contract to Azure, should have been enough to internally kick off some prioritization meetings as, on its face, it proves that .NET is an "enterprise-level" endeavor and should be treated as such. Instead of wasting resources trying to "sue" over the decision, use those resources internally to give the .NET community some love. Use this as a moment to re-prioritize .NET so that next .NET release, AWS is on top of it, and makes self-evident that they are ready to hit the ground running.

@normj, @martincostello, and the rest of the worker bees over there at AWS, working really hard to provide a SOLID .NET offering, please understand that these (community) complaints are not with you per se, but more the culture/politics that dictate the priority mandate that you have been given with regards to .NET. Please use this post to help achieve "enterprise-level" support.

[CumpsD]

I mainly see this as a missed opportunity for AWS to shine. Imagine if following a new LTS release would be a high priority. What a strong statement it would be.

Things like this make us developers/architects lose arguments against non-technical decision-makers when we need to decide on which cloud to use for the next project. These days when both Azure and AWS have mostly equal cost and feature offerings, decisions are more made on politics and perception. I have nothing to bring when they say "it's been X weeks/months after the official release and AWS is still not ready"

Again, like @VagyokC4 says, this is not personal against the employees doing the actual work, but more of a wake-up call for upper AWS management.

[CraigHead]

Everyone doing .NET Core 3.1 Lambda's might consider enabling IL Trimming. Most likely you're going to reduce the size of your zip files. https://www.hanselman.com/blog/MakingATinyNETCore30EntirelySelfcontainedSingleExecutable.aspx

[petarrepac]

is .NET core lambda 3.1 built using RuntimeAPI? in the open, on github? if no, why not?

[cdesallegdf]

All I want for.... Valentines day is lambda .net core 3.1 support

[clearwaterstream]

All I want for.... Valentines day is lambda .net core 3.1 support

Doesn't exactly roll off the tongue, but it's hummable:

I don't want a lot for Christmas Valentine's Day There is just one thing I need I don't care about the presents Underneath the AWS tree I just want it for my own More than you could ever know Make my wish come true oh All I want for Valentine's Day is .NET Core 3.1 suppooooort ...

:grin:

[buvinghausen]

Microsoft includes Go Live licenses towards the end of their preview cycle when they won't be introducing any breaking changes. By that point they offer production support for that upcoming release. My recommendation would be wait until they make a release with a Go Live license and then begin working on the tooling. With .NET Core 3.1 it came in Preview 3 which was released on 11/14. In this case the RTM was not even 3 weeks later on 12/3 but still you'd be closer to rolling the features out when RTM hits and customers start to build expectations.

Just my $0.02

[keserwan]

All I want for.... Valentines day is lambda .net core 3.1 support

Doesn't exactly roll off the tongue, but it's hummable:

I don't want a lot for ~Christmas~ Valentine's Day There is just one thing I need I don't care about the presents Underneath the AWS tree I just want it for my own More than you could ever know Make my wish come true oh All I want for Valentine's Day is .NET Core 3.1 suppooooort ...

😁

+1 :)

[a-patel]

any update on .NET Core 3.1 runtime for Lambda?

[CumpsD]

We're starting a new project and were heavily leaning to using Lamba for the majority of serverless, but seeing how long it takes to get an LTS version supported is making us rethink, possibly changing architecture or provider.

[CraigHead]

<Rant> It's frustrating that he AWS Lambda Runtime support policy is very strict about 30 day window, when features like this are asked for longer than 30 days. Then magically one day AWS will deploy this feature and everyone else will have to scramble to switch over to .NET Core 3.1. This puts MOST organizations in bad spot since often times it takes longer than a month to fix, test, and deploy something to a production environment. I've personally been bit in the butt by this policy. Once (because resource constraints and other higher priorities) a company I was at let this time slip. It wasn't until 3 months later that we could upgrade our Lambdas to .NET Core 2.1. Once we tried to deploy a particular lambda with CloudFront, something bad (what? who knows because CF logs are garbage) happened and it needed to rollback. Except there wasn't a runtime to rollback to. Thus it LOCKED the deployment. We immediately opened a ticket. 24 hours later we got our first response which was "delete the whole stack and start over". Which is a completely ignorant response considering it would had taken our DynamoDb tables with the "delete" operation. We were locked in that rollback for over 2 and a half weeks. Eventually we got a support engineer who understood container technologies and helped us rollback and then stayed on the line until our CloudFormation succeeded. Which it did fine, no change to the first attempt. Which is sorta why I now hate CF, since it's too temperamental to use. </Rant>

TL;DR; The AWS Lambda Runtime Support policy is unpleasant to work with and can get you into hot water. https://docs.aws.amazon.com/lambda/latest/dg/runtime-support-policy.html

[normj]

@CraigHead sorry for your frustrating experience but to be clear regardless of when .NET Core 3.1 is released on Lambda the .NET Core 2.1 runtime will be supported in Lambda till at least August 21, 2021 based on Microsoft support cycle. There will be no need to rush to convert 2.1 functions to 3.1. I assume your previous experience was with the .NET Core 2.0 which was an anomaly for Lambda because it was the only non LTS version to go into Lambda. That was only done due to some major issues with .NET Core 1.0.

[CraigHead]

Yup, it was the migration off .NET Core 2.0 forward to .NET Core 2.1. Sorry about the rant. 30 days is kinda tight for some of us. Looking at the over-all length a lambda could potentially run without significant maintenance and additional QA.