Aws-lambda-dotnet: .NET Core 3.1 (LTS) has been released

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

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.

Will there be a speedup for the cold start time?

.NET Core 3.1 has some features like AOT compile

• PublishReadyToRun
• PublishTrimmed

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

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.

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 :)

Any update here?

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

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

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

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

@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 :)

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.

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

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

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.

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! :)

waiting for lambda native support on .NetCore3.1

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.

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.

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.

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:

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

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?

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.

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

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.

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.

"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

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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

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

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:

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

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 :)

any update on .NET Core 3.1 runtime for Lambda?

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.

<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

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

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.

meanwhile, this is happening on the Azure side of serverless
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

Meanwhile the AWS team are working on it. Snarky comments isn't helping
them. They'll update this issue when it's ready.

On Tue, 11 Feb 2020 at 18:22, Rati Dzidziguri notifications@github.com
wrote:

meanwhile, this is happening on the Azure side of serverless

https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AAAZVJXAAYET4F7PFFOTO3LRCLUETA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELNQMBY#issuecomment-584779271,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAZVJQK3NBVXBZALM4V5KLRCLUETANCNFSM4JU5UTJA
.

My point was not to put snarky comment but to point out that even MS announced GA availability for 3.1 recently, so I hope to see AWS finalizes their work on 3.1 support soon.
.

meanwhile, this is happening on the Azure side of serverless
https://visualstudiomagazine.com/articles/2020/01/30/azure-functions-3-0-runtime.aspx

Considering its an MS language it isn't surprising Azure beat AWS to supporting this.

Watching this thread closely - looking forward to upgrading my C# Lambdas.

dotnet core 3.1.0 was released 2019-12-03
https://dotnet.microsoft.com/download/dotnet-core/3.1

it was available in Azure on 2020-01-23
https://azure.microsoft.com/en-us/updates/azure-functions-runtime-30-is-now-available/

we are a bit short of one additional month compared to Azure

BTW, all .NET core development is done in the open on github
So, being "MS language" should not have much effect.
Or you suggest AWS Clients using dotnet are better of on Azure :P ?

Anyway, to anyone listening on AWS:
there are us waiting for 3.1 on Lambda, it's important to us.

BTW, all .NET core development is done in the open on github
So, being "MS language" should not have much effect.
Or you suggest AWS Clients using dotnet are better of on Azure :P ?

I mean, it would be a bit embarrassing for Microsoft's Cloud Platform not to support the new features of their own language. To be honest, I'm a little surprised it took them a little more than a month and a half! A little more internal communication would perhaps have allowed both to be released at the same time.

I think AWS are doing well with their .Net support, especially with development packages that hook into their services such as CloudWatch + ILogging and their SSM parameter configuration tie in. It's helped us greatly.

Hope to see the 3.1 release soon though :)

I do wish there was a better Cloudwatch concrete implementation of ILogger. This would be better integrated into the ServiceCollection/ServiceProvider when using the Lambda SDK. The current version that is provided in the request context and the static LambdaLogger class is basically impossible to unit test / verify log output and hooking the default .netcore ConsoleLogProvider results in messy Cloudwatch logs.

I do wish there was a better Cloudwatch concrete implementation of ILogger.

Have you tried https://github.com/aws/aws-logging-dotnet#aspnet-core-logging ?

What do you want your logs to look like @CraigHead?

We have used Serilog & https://github.com/structured-log/structured-log in the past to output nice console logs and also JSON based logs that were imported into Seq. https://datalust.co/ that was the best way for us to get central logs in a really nice format.

@CraigHead Amazon.Lambda.Logging.AspNetCore is our implementation to integrating Lambda's logging into the IServiceCollection. Does that library not work for you.

I would not recommend the AWS.Logger.AspNetCore package from ttps://github.com/aws/aws-logging-dotnet#aspnet-core-logging for Lambda. That library uses a background thread to push logs to CloudWatch Logs. Using a background thread like that doesn't play well with Lambda which freezes the Lambda compute environment as soon as the function handler returns which means the background thread might not get a chance to flush the queued messages.

I didn't know about this. Thank you for the tip!
I was referring to the Amazon.Lambda.Core.LambdaLogger in the SDK.
I will definitely check that package (Amazon.Lambda.Logging.AspNetCore) out.

https://docs.aws.amazon.com/lambda/latest/dg/csharp-logging.html

@clearwaterstream
In lambda-land AFAIK there is no event that will notify you that current instance will stop processing or will be terminated, so your suggestion will still leave buffered log events non-flushed (lost).

Please don't hijack this thread for other needs.
This thread was created to give some info when .NET Core 3.1 on AWS Lambda will be available.
And to let AWS know we are out there and waiting.

Will the lambda test tool be included in the 3.1 release? https://github.com/aws/aws-lambda-dotnet/tree/master/Tools/LambdaTestTool

That is my intention. The work is going on in the mock-testtool-31. The big improvement in the 3.1 branch is the user Lambda code is now running in a separate AssemblyLoadContext which should fix a lot of the version conflicts users had with the current version. I'm looking at back porting the AssemblyLoadContext feature to the into the 2.1 version.

As a side note. I have debating about converting the bare bones UI to be a server side Blazor app. Does anybody with more Blazor experience have any feedback on whether that is a good or bad idea?

As a side note. I have debating about converting the bare bones UI to be a server side Blazor app. Does anybody with more Blazor experience have any feedback on whether that is a good or bad idea?

Anything Blazor at this point is a good idea, especially for those of us rocking DotNet!

"bare bones UI" - this is some other app, non connected to .NET Core 3.1 Lambdas?
BTW, I don't care about blazor at all

@petarrepac This was in reference to the AWS .NET Mock Lambda Test Tool that we shipped to help debug .NET Core 2.1 Lambda functions. Here is the post for reference https://aws.amazon.com/blogs/developer/debugging-net-core-aws-lambda-functions-using-the-aws-net-mock-lambda-test-tool/

I'm in the process of updating the tool for .NET Core 3.1.

@normj
ah, didn't get that, thanks
it's interesting thought, that we never needed such a tool

from our perspective lambda is a barebone AspNetCore HttpApi you can call locally and test locally
the only difference is entry point file/class that is under 50 lines of code
also, a lot of things can only be properly tested when deployed to AWS:

• permissions
• shape of received JSON events and context
• ...
  so, a combination of:
• good unit/integration tests running locally
• local http testing
• easy to deploy to test aws environment
  can go far

or I'm missing some obvious scenario?

@petarrepac That is one of the big benefits of using the ASP.NET Core bridge is it is really easy to run locally. I agree the best practice is to use unit/integration testing but there are often needs for quick adhoc testing of application logic and that is what this tool is good for.

Thank you @normj. In regards to Blazor, it could be a nice touch. For our team’s use case at least it would probably go under utilized.

We are only in the UI long enough to send a payload, then stepping through the code in VS.

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.

@martincostello

I'm having some trouble pulling this off based on your explanation. I have about 20 Lambda functions in my Functions.cs that are tied to corresponding definitions in my serverless.template. I understand you would be passing an environment variable with each definition to indicate which function to call. Most of these functions are of the signature:

public APIGatewayProxyResponse ThisLambdaFunction(APIGatewayProxyRequest request, ILambdaContext context)
{

How do add support for different lambda function signatures, if I have other functions that take different arguments (other than APIGatewayProxyRequest ) and different return types ?

Please do not derail the thread.

@twopointzero I've spent days Google searching for a solution to running multiple lambda functions using .NET Core 3.1 Custom Runtime project. There is no more relevant thread on the internet and I'm replying to an existing post that provided a glimmer of hope that there's a solution to my problem.

Not having native .NET Core 3.1 support in AWS is making life difficult. We need to upgrade to 3.1 in order to upgrade to latest EntityFramewore Core 3.1.2, which fixes issues we are seeing with connection pooling in Aurora (PostgresSQL).

@normj I completely understand the no ETA stance but can you tell me if we are close? < 30 days?

@antsaia With respect, your comment was in relation to deployment of a distributed monolith using custom runtime support, not in relation to AWS Lambda support for .NET Core 3.1. If you cannot find a more relevant thread on the internet, I would kindly request that you create one rather than derail one.

So as to not derail this thread myself, this is my final comment on the matter.

@normj is there any resource available (blog, forum, etc.) where we can obtain information about the status of the .net core 3.1 support implementation?

I visit this page daily with the hope to obtain any new information but obviously there's not enough information (as it is not intended for that use). It would make it a lot easier if we had some sort of basic update so we can plan ahead.

Like many here our plans for delivering features are very much dependent on whether we can use 3.1 or if we have to develop it using 2.1. In my case 3.1 will be providing support for System.Draw and this has a major impact on the feature I am to work on.

All I want for.... St. Patrick's day is lambda .net core 3.1 support

@liam-sage all I could find were a few posts on the amazon forum indicating it would be ready in Q1 2020. https://forums.aws.amazon.com/thread.jspa?threadID=313806

@liam-sage all I could find were a few posts on the amazon forum indicating it would be ready in Q1 2020. https://forums.aws.amazon.com/thread.jspa?threadID=313806

This means it must go live in March. I'm awaiting.

Hi, I know it's not completely suitable but you can get your own lambdas updated to dotnetcore 3.1. In the meantime while you wait I would suggest if you create lots of lambdas to write your own dotnetcore template. I did that for my own. I wanted to ensure that I don't have to waste hours with boilerplate code. An example of a template can be found here .

And Vincent, How do we host it there? using custom runtime?
On Thu, Mar 5, 2020 at 7:40 PM Vincent van der Walt <
[email protected]> wrote:

Hi, I know it's not completely suitable but you can get your own lambdas
updated to dotnetcore 3.1. In the meantime while you wait I would suggest
if you create lots of lambdas to write your own dotnetcore template. I did
that for my own. I wanted to ensure that I don't have to waste hours with
boilerplate code. An example of a template can be found here
https://github.com/vincentvanderwalt/aws-lambda-dotnetcore-3-template.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AGIDH4OWUT7Y3HR3O5KARBDRF62V3A5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEN5P2CY#issuecomment-595262731,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGIDH4PLKFSDLNBX2QVMG63RF62V3ANCNFSM4JU5UTJA
.

Yes it makes use of the custom runtime.

You can run it locally on your machine or deploy to aws.

F5 for local and dotnet lambda deploy-serverless for deployment to aws

The readme explains how to install the template to your local machine (it's a dotnetcore template)

Custom runtimes are cool, but I'm still waiting for the full AWS support for .Net Core 3.1 for lambdas to use them in production environments 😄

Every time I see this in my inbox, I eagerly open it to see if @normj has
announced anything only to find a posting that is at least a little bit off
topic. Someone else asked others not to hijack the thread and that hasn't
worked. Can someone lock the thread until someone is ready to announce the
release of 3.1 support?

On Fri, Mar 6, 2020 at 7:13 AM bartoszsiekanski notifications@github.com
wrote:

Custom runtimes are cool, but I'm still waiting for the full AWS support
for .Net Core 3.1 for lambdas to use them in production environments 😄

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554?email_source=notifications&email_token=AAVUT3SNDR4L2ZL5J4KQYDDRGDSHBA5CNFSM4JU5UTJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOBE2OI#issuecomment-595742009,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAVUT3TBH3NIBMGB54EFCR3RGDSHBANCNFSM4JU5UTJA
.

Please create separate issues for anything else than discussing .NET Core 3.1 support. Can I close this issue until we have more news @normj ?

@hounddog22030 I didn't realise I was 'hijacking' the thread. I was suggesting that rather than constantly asking if it's ready, that there are alternative approaches if people are desperate to move to dotnetcore 3.1. Official non custom-runtime support will be ready when it's ready. People just have to be a little more patient or seek an alternative approach.

If AWS supports --self-contained option in dotnet lambda package command, the lambda functions must be executable regardless of their SDK version. right? Why not doing that instead of adding support for every .NET Core release?

If AWS supports --self-contained option in dotnet lambda package command, the lambda functions must be executable regardless of their SDK version. right? Why not doing that instead of adding support for every .NET Core release?

You just described lambda custom runtime feature

@aussiearef That indeed works well, but the self-contained package includes .Net Core itself, which typically adds up to at least 40MB (zipped) for a website -- leaving not much room for the application and dependencies itself.

When using the same version of .NET core, custom runtime is also slower (cold starts) than native runtime. 3.1 adds a lot of performance improvements, so you can excpect the same level of perfs between 3.1 custom fully optimized and 2.1 native. I have hopes that 3.1 native will bring significative improvements.

Q1 will end in 4 days, but it looks like we will not see 3.1 in lambda.
I hope all the members of the team are safe in this pandemic time and hope to see this release in Q2.

Don't give up hope we have a few days left! We are all pretty much wrapped up waiting on final deployments and other last minute activities. Keep in mind we all know software and there could be last minute hiccups.

I actually plan on beginning a roll out of the new client tooling updates soon to make sure everything is available once the runtime is opened up. So if you see new NuGet package updates go out don't assume the runtime is there. Wait till blog post is out and I will post an update here.

That’s fantastic news. Thank you @normj

Looking forward to the blog post and release.

Don't give up hope we have a few days left! We are all pretty much wrapped up waiting on final deployments and other last minute activities. Keep in mind we all know software and there could be last minute hiccups.

I actually plan on beginning a roll out of the new client tooling updates soon to make sure everything is available once the runtime is opened up. So if you see new NuGet package updates go out don't assume the runtime is there. Wait till blog post is out and I will post an update here.

Your patience in the face of the attitude in this thread is beyond impressive. Thanks for working on this!

@normj happy to assit with any testing you may wish to do prior to publishing ;)

2 more days to go and fingers crossed.

And its out with 13 hours left in the quarter 😅

https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

Thanks everybody for your patiences. @raRaRa I will leave you the honor of closing this issue.

Great

On Tue, 31 Mar 2020, 20:06 Norm Johanson, notifications@github.com wrote:

And its out with 13 hours left in the quarter 😅

https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

Thanks everybody for your patiences. @raRaRa https://github.com/raRaRa
I will leave you the honor of closing this issue.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554#issuecomment-606785798,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AGUX3OUR6LN5CERIBTDHXP3RKIWLVANCNFSM4JU5UTJA
.

thank you!!!!

And.... UnSubscribe :-)

Thanks to all involved!!!

Thanks!

And its out with 13 hours left in the quarter 😅

https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

Thanks everybody for your patiences. @raRaRa I will leave you the honor of closing this issue.

Nice work!

That is AWS baby. That is AWS!!!
No matter what happens, in the end, they get it done.

Thanks a lot, team!!!

Great news and much thanks @raRaRa @normj !!! At the risk of sounding foolish and/or greedy does this also intrinsically mean Powershell 7 as well? Just double checking......

Great job @normj and everyone at AWS! 🥳

Here's the link to the blog for those scrolling to the bottom
https://aws.amazon.com/blogs/compute/announcing-aws-lambda-supports-for-net-core-3-1/

awesome, thanks a million for adding support to dotnet core 3.1!!!

@andyKalman Not yet on PowerShell 7. I'm doing some final touch ups on the AWSLambdaPSCore module and then will get that released the 2.0.0 version of AWSLambdaPSCore to the gallery.

I appreciate the quick reply @normj . I did see #607 after the fact so good to see it looks to be a quick followup. Is there another issue to track so I can stop the comments here? :) Thanks again.

Congrats!
And thank you AWS and .NET Team!
Much appreciated.

Thank you to everyone who helped make this happen! This is a huge release and it shows a lot of hard work went into it! Nice! 🎉🥳

Thanks!! :clap: :clap: :tada: :tada:

Congrats guys, looking forward to upgrading.

Thanks!

Awesome work, keen to upgrade these lambdas.

Great work! Thank you @normj 👏 👏

Great work Team!

Eager to jump on Lambda workers with dotnet 3.1 Async Streams +AWS AppSync/GraphQL subscriptions.
AWS Team, Many Many Thanks !

OMG, guys you rules! Amazing! Woohoo! 😄😄😄

THANKS!

@andyKalman I pushed out version 2.0.0 of the AWSLambdaPSCore module which now uses PowerShell 7. I'm planning on putting out a blog post on the PS7 support but it acts the same as the existing PowerShell 6 support just uses 7.

@andyKalman I pushed out version 2.0.0 of the AWSLambdaPSCore module which now uses PowerShell 7. I'm planning on putting out a blog post on the PS7 support but it acts the same as the existing PowerShell 6 support just uses 7.

Does the new version of AWSLambdaPSCore update any of the configurations within my existing Lambda functions if i publish them with the new version? Like will it point it towards dotnet3.1 and ps7?

@tr33squid Yes if you deploy with 2.0.0 it will use .NET Core 3.1 and PS7

Thanks a lot and great job AWS team!!

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.

Thanks to AWS-Lambda .NET core team

Hi,
I am getting this error when trying to execute AWS-Lambda
It was not possible to find any compatible framework version.
The specified framework 'Microsoft.AspNetCore.App', version '3.1.0' was not found.
any suggestions ??

Hi,
I am getting this error when trying to execute AWS-Lambda
It was not possible to find any compatible framework version.
The specified framework 'Microsoft.AspNetCore.App', version '3.1.0' was not found.
any suggestions ??

You need to install the 3.1.0 SDK.

I believe Microsoft.AspNetCore.App should be removed from your project
dependencies, not anymore needed for Core 3.1.0, I had to remove it to
build and deploy the service I upgraded from 2.1.

On Fri, Apr 24, 2020 at 3:24 AM Gregory Lyons notifications@github.com
wrote:

Hi,
I am getting this error when trying to execute AWS-Lambda
It was not possible to find any compatible framework version.
The specified framework 'Microsoft.AspNetCore.App', version '3.1.0' was
not found.
any suggestions ??

You need to install the 3.1.0 SDK.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/aws/aws-lambda-dotnet/issues/554#issuecomment-618850277,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AMSHCOLW5WJDS7CCAFDMP4TROE5ENANCNFSM4JU5UTJA
.

--
Best,
George

George Taskos
Senior Solutions Architect

WeAre8
230 Park Avenue, 3th fl. West
New York, NY 10169
(917) 717-9067
weare8.com

Private Entrance,
71 Vanderbilt Ave
3rd Floor

I believe Microsoft.AspNetCore.App should be removed from your project dependencies, not anymore needed for Core 3.1.0, I had to remove it to build and deploy the service I upgraded from 2.1.
…
On Fri, Apr 24, 2020 at 3:24 AM Gregory Lyons @.*> wrote: Hi, I am getting this error when trying to execute AWS-Lambda It was not possible to find any compatible framework version. The specified framework 'Microsoft.AspNetCore.App', version '3.1.0' was not found. any suggestions ?? You need to install the 3.1.0 SDK. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#554 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMSHCOLW5WJDS7CCAFDMP4TROE5ENANCNFSM4JU5UTJA .
-- Best, George George Taskos Senior Solutions Architect WeAre8 230 Park Avenue, 3th fl. West New York, NY 10169 (917) 717-9067 weare8.com Private Entrance, 71 Vanderbilt Ave 3rd Floor

Thanks for your reply,
Actually this error was due to my silly mistake. I forgot to remove runtime: dotnetcore2.1 in my serverless.yml. Now issue solved.

Anyone do any updated benchmark/comparisons on this? All I can find are old ones with a custom runtime..

Anyone do any updated benchmark/comparisons on this? All I can find are old ones with a custom runtime..

Here is a good one.
https://medium.com/@zaccharles/a-close-look-at-net-core-3-1-on-aws-lambda-9ccec4dd96be

Also my personal experience updating a 2.1 complex lambda to 3.1 on a 512mb lambda size saw almost exact same performance (cold and warm start). Both the 2.1 and 3.1 lambda uses lambda layer, optimized publish, newtonsoft (might see perf improvement with Microsoft json in 3.1), tiered compilation off, and RTR for 3.1.

From my metrics, it seems to gain slight performance with dotnet 3.1 runtime, but lose performance on Amazon Linux 2 and dotnet 3.1 initialization. (2.1 uses Amazon Linux 1.) Making gains a wash.