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

[rati-dzidziguri]

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

[jchannon]

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 .

[rati-dzidziguri]

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

[Jono20201]

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.

[petarrepac]

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.

[Jono20201]

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

[CraigHead]

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.

[Jono20201]

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 ?

[andymac4182]

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.

[normj]

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

[CraigHead]

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

[petarrepac]

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

[petarrepac]

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.

[BrendenAZ]

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

[normj]

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?

[VagyokC4]

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!

[petarrepac]

"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

[normj]

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

[petarrepac]

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

[normj]

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

[BrendenAZ]

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.

[antsaia]

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 ?

[twopointzero]

Please do not derail the thread.

[antsaia]

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

[twopointzero]

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

[liam-sage]

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

[cdesallegdf]

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

[joel-morland]

@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

[martonx]

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

[vincentvanderwalt]

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 .

[alirafique99]

And Vincent, How do we host it there? using custom runtime? On Thu, Mar 5, 2020 at 7:40 PM Vincent van der Walt < notifications@github.com> 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 .

[vincentvanderwalt]

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)

[bartoszsiekanski]

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 😄

[hounddog22030]

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 .

[raRaRa]

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 ?

[vincentvanderwalt]

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

[aussiearef]

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?

[Thiago-Dantas]

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

[aidansteele]

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

[madmox]

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.

[rati-dzidziguri]

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.

[normj]

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.

[vincentvanderwalt]

That’s fantastic news. Thank you @normj

Looking forward to the blog post and release.

[gregorylyons]

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!

[3GDXC]

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

[rati-dzidziguri]

2 more days to go and fingers crossed.

[normj]

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.

[ahmadwaquar88]

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 .

[clearwaterstream]

thank you!!!!

[bobhaffner]

And.... UnSubscribe :-)

Thanks to all involved!!!