aspnetcore: IHostingEnvironment changes break Serverless ASP.NET Core with AWS Lambda
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?
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 1
- Comments: 18 (11 by maintainers)
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 targetnetcoreapp3.0. To pull in the dependency they will need to addFrameworkReferencetoMicrosoft.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.
@davidfowl My preferred approach for this change would been to leave
HostingEnvironmentalone onWebBostBuilderContextbut make it obsolete and then add a new property forIWebHostEnvironment.The breaking change on
WebBostBuilderContextis 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.