IHostingEnvironment changes break Serverless ASP.NET Core with AWS Lambda

[normj]

Describe the bug

This isn't really a bug report but more of request for guidance. I maintain the package Amazon.Lambda.AspNetCoreServer which allows running an ASP.NET Core application in a serverless fashion without kestrel.

The library is a netstandard2.0 library making it easy to plugin for ASP.NET Core 2.0, 2.1 or 2.2. I was testing the library on the .NET Core 3.0 preview 4 and it is failing with following exception during startup.

Unhandled Exception: System.MissingMethodException: Method not found: 'Microsoft.AspNetCore.Hosting.IHostingEnvironment Microsoft.AspNetCore.Hosting.WebHostBuilderContext.get_HostingEnvironment()'.
   at Amazon.Lambda.AspNetCoreServer.AbstractAspNetCoreFunction`2.<>c.<CreateWebHostBuilder>b__13_1(WebHostBuilderContext hostingContext, ServiceProviderOptions options)
   at Microsoft.AspNetCore.Hosting.WebHostBuilderExtensions.<>c__DisplayClass6_0.<UseDefaultServiceProvider>b__0(WebHostBuilderContext context, IServiceCollection services)
   at Microsoft.AspNetCore.Hosting.WebHostBuilder.BuildCommonServices(AggregateException& hostingStartupErrors)
   at Microsoft.AspNetCore.Hosting.WebHostBuilder.Build()
   at Amazon.Lambda.AspNetCoreServer.AbstractAspNetCoreFunction`2.Start() in C:\codebase\aws-lambda-dotnet\Libraries\src\Amazon.Lambda.AspNetCoreServer\AbstractAspNetCoreFunction.cs:line 210
   at LambdaConfigureTest.Program.Main(String[] args) in C:\Users\Norm\Source\Repos\LambdaConfigureTest\LambdaConfigureTest\Program.cs:line 28

The code that is triggering the behavior can be found here.
https://github.com/aws/aws-lambda-dotnet/blob/master/Libraries/src/Amazon.Lambda.AspNetCoreServer/AbstractAspNetCoreFunction.cs#L149-L168

I understand this is happening due to @Tratcher change which changed the return type of the property HostingEnvironment from IHostingEnvironment to IWebHostEnvironment. Which I see he announced here. I'm not sure this change takes libraries like mine that have to target multiple versions of ASP.NET Core into account.

The solution I have thought of so far is add separate build version for netcoreapp3.0 which leads me down the path of having to have a separate version for all future versions of ASP.NET Core which I would rather not do. When making this breaking change was there a discussion on how library authors would be expected to handle the change?

[Tratcher]

This kind of break can only be handled by multi-targeting. Based on your usage you probobly wouldn't even need #if's in your code, but you do need to produce a version of your library compiled for 3.0.

It's actually not much extra work. You add a second TFM here:
https://github.com/aws/aws-lambda-dotnet/blob/c25d5554a971d347c59ab29a294e1c1279f89fab/Libraries/src/Amazon.Lambda.AspNetCoreServer/Amazon.Lambda.AspNetCoreServer.csproj#L7
and the built nuget package will contain both versions so your consumers don't need to move to a different package.

[Tratcher]

In general, it's not unexpected that a library would need to be recompiled for each major version.

[davidfowl]

Did we change the WebBostBuilderContext? I guess at this point it isn’t legacy but we tried to avoid breaking people in general with this change. Maybe worth looking to see if we add a new property typed as IWebHostEnvironment instead of changing the existing one

[Tratcher]

We could try to mitigate it, but I'd still expect libraries will need to re-compile for 3.0 for many other reasons, no?

In this case of this property there's minimal disruption if you recompile.

[normj]

@davidfowl My preferred approach for this change would been to leave HostingEnvironment alone on WebBostBuilderContext but make it obsolete and then add a new property for IWebHostEnvironment.

The breaking change on WebBostBuilderContext is a subtle change especially to library authors with a fairly easy mitigation preventing the breaking change. I assumed the change was done thinking it would be simple for applications which would have to be recompiled anyway.

@Tratcher Yes the code change is small by just adding netcoreapp3.0 to the TFM but the build changes are not. That would require us to install a preview version of the .NET Core SDK on our production build servers. I know you guys have a high bar for preview SDK but that is still not something we are likely to do. So that means this library wouldn't be updated till ASP.NET Core 3.0 goes GA which is disappointing because I was attempting to see how the new services.AddControllers() could improve performance.

I do understand breaking changes happen and one of the goals with .NET Core was to have the flexibility to allow it to innovate which you guys have been doing a great job of. But be careful with the mindset that "it's is not unexpected that a library would need to be recompiled for each major version". That sounds like dragging .NET Core back to PCL hell which .NET Standard was supposed to fix. I would expect applications to have to recompile for every major version and library authors to test on every new version to confirm the library still works.

Is it expected all of ASP.NET Core library will target netcoreapp3.0? I was hoping they would either stay at netstandard2.0 or move to netstandard2.1.

[davidfowl]

Is it expected all of ASP.NET Core library will target netcoreapp3.0? I was hoping they would either stay at netstandard2.0 or move to netstandard2.1.

ASP.NET Core 3.0 requires netcoreapp3.0. The core of it is no longer a set of packages but a framework reference built into .NET Core 3.0. If you don't need any of the 3.0 APIs and if you don't encounter any of the breaking changes then it is possible to keep working with the old packages that will just run on ASP.NET Core 3.0. To get the best experience in terms of dependencies though, cross compiling to netcoreapp3.0 would be ideal (since so many of the old dependencies that are now baked in)

I do understand breaking changes happen and one of the goals with .NET Core was to have the flexibility to allow it to innovate which you guys have been doing a great job of. But be careful with the mindset that "it's is not unexpected that a library would need to be recompiled for each major version". That sounds like dragging .NET Core back to PCL hell which .NET Standard was supposed to fix. I would expect applications to have to recompile for every major version and library authors to test on every new version to confirm the library still works.

.NET Standard doesn't fix this, it is mainly about code sharing across Xamarin, .NET Core and .NET Framework. We're going to make breaking changes in major versions (hopefully not frivilously) and libraries will need to cross compile if they run into one of those situations. You'll also need to cross compile if you want to use new APIs and that's something that hasn't changed since the beginning of .NET (Framework or Core).

Is it expected all of ASP.NET Core library will target netcoreapp3.0? I was hoping they would either stay at netstandard2.0 or move to netstandard2.1.

You may have missed the memo on this:

• https://devblogs.microsoft.com/aspnet/a-first-look-at-changes-coming-in-asp-net-core-3-0/
• ASP.NET Core 3.0 will only run on .NET Core aspnet/Announcements#324

TL;DR ASP.NET Core 3.0 is .NET Core 3.0 only which means libraries that want to target it must cross compile to .NET Core 3.0.

PS: Extensions will remain ns2.0 and 2.1 and netcoreapp3.0 in some cases

[davidfowl]

Let’s fix this.

[davidfowl]

cc @anurse @glennc

[Tratcher]

By adding a new property and obsoleting the old one? That's going to result in a lot more warnings and churn internally and externally. Folks re-targeting to 3.0 likely didn't have to change any code before, now they all have to change.

[normj]

That would be great if this was fixed and unblock testing serverless 3.0 ASP.NET Core apps again. It is a very subtle breaking change that is I'm sure my library is not the only one affected.

I did see that ASP.NET Core 3.0 will only target .NET Core 3.0, I just didn't realize the ramifications to library authors. So as I understand things now if a library takes a dependency on Microsoft.AspNetCore.* they will have to target netcoreapp3.0. To pull in the dependency they will need to add FrameworkReference to Microsoft.AspNetCore.App. I just discovered that when netcoreapp3.1 or netcoreapp4.0 are released a netcoreapp3.0 version of the library will roll forward to the future versions of the framework. Although it is still up to the library author to ensure the library works in newer versions. If the library author finds a breaking change then add a new TFM to the NuGet package for the new version.

One problem I think we will struggle with is if we add the netcoreapp3.0 version into the NuGet package it will be a slow process for us to remove it because we wouldn't want to remove it till we knew a very high percentage of the users have migrated to newer versions which always takes longer then you would like. That means our build server is always going to need a .NET Core 3.0 install even when it is out of support. Since .NET Core 3.0 won't be an LTS it could go out of support pretty quickly like .NET Core 2.0 was. That puts our build servers at a potential security risk. So ideally requiring library authors to add a specific netcoreapp version TFM unlike a .NET Standard TFM would be better when it is an LTS version.

If you are looking for blog ideas one that talks about how libraries should take dependency on ASP.NET Core now that ASP.NET Core targets .NET Core 3.0 could be a good one.

I do disagree that .NET Standard is "mainly about code sharing across Xamarin, .NET Core and .NET Framework." as it is still the best way to write a library for .NET Core and have it work for any future versions of .NET Core. But I can understand the stance that writing libraries for ASP.NET Core requires a different level of dependency management then writing more libraries that rely on just the BCL like the AWS SDK for .NET or Azure .NET SDK which both target .NET Standard.

[hugosmarques]

Hello @normj

Did you found a solution for this issue? Im trying to running a .Net Core 3 code on Lambda and i get the same error:

Unhandled Exception: System.MissingMethodException: Method not found: 'Microsoft.AspNetCore.Hosting.IHostingEnvironment Microsoft.AspNetCore.Hosting.WebHostBuilderContext.get_HostingEnvironment()'.

Did you have any workround for now?

[davidfowl]

There's no workaround.

cc @anurse @DamianEdwards

[hugosmarques]

So we can't use .Net Core 3 with Amazon.Lambda.RuntimeSupport?

[davidfowl]

That's right, at the moment there's a breaking change preventing it from working. @normj Would need to make a new build of the integration package to make it work.

[hugosmarques]

Ok @davidfowl thanks.
@normj did you have an idea when you could make this new build?

[NoraBo]

I am still having the same issue when running a serverless .net core 3.0 web API with AWS Lambda that uses Amazon.Lambda.RuntimeSupport as shown below:

Unhandled Exception: System.MissingMethodException: Method not found: 'Microsoft.AspNetCore.Hosting.IHostingEnvironment Microsoft.AspNetCore.Hosting.WebHostBuilderContext.get_HostingEnvironment()'.
at Amazon.Lambda.AspNetCoreServer.AbstractAspNetCoreFunction2.<>c.<CreateWebHostBuilder>b__13_0(WebHostBuilderContext hostingContext, IConfigurationBuilder config) at Microsoft.AspNetCore.Hosting.WebHostBuilder.BuildCommonServices(AggregateException& hostingStartupErrors) at Microsoft.AspNetCore.Hosting.WebHostBuilder.Build() at Amazon.Lambda.AspNetCoreServer.AbstractAspNetCoreFunction2.Start()
at Amazon.Lambda.AspNetCoreServer.AbstractAspNetCoreFunction2..ctor(StartupMode startupMode) at Amazon.Lambda.AspNetCoreServer.AbstractAspNetCoreFunction2..ctor()
at Amazon.Lambda.AspNetCoreServer.APIGatewayProxyFunction..ctor()
at AWSServerless1.LambdaEntryPoint..ctor()
at AWSServerless1.LocalEntryPoint..cctor() in LocalEntryPoint.cs:line 18

In https://aws.amazon.com/blogs/developer/announcing-amazon-lambda-runtimesupport/, it is stated that .net core 3.0 should be supported in Amazon.Lambda.RuntimeSupport.

• @normj When are you planning to release a fix for the above issue?
• Did we manage to find a workaround for this issue?

Thanks.

[normj]

I have created the following issue in our AWS .NET Lambda repo aws/aws-lambda-dotnet#481 to track the work on our side.

I have also created a sample in my samples repo that contains a custom built version of Amazon.Lambda.AspNetCoreServer in the nuget-cache directory. The changes in that custom version will be merged into the main branch when .NET Core 3.0 goes GA.

[ghost]

Thank you for contacting us. Due to a lack of activity on this discussion issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.

This issue will be locked after 30 more days of inactivity. If you still wish to discuss this subject after then, please create a new issue!