-
Notifications
You must be signed in to change notification settings - Fork 10k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate the Microsoft.AspNetCore.App metapackage in favor of targeting and runtime packs #7832
Conversation
We need to do https://github.com/dotnet/cli/issues/10442 before you stop producing the runtime.$(rid).Microsoft.AspNetCore.App packages |
I see https://github.com/dotnet/cli/issues/10442 is marked as |
I think the |
Which file list, the platform manifest? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One bit is confusing me but, otherwise (once unblocked and builds pass),
cc @anurse |
After this merges, anything still using a package reference to Microsoft.AspNetCore.App will stop getting updates. The new packages, Microsoft.AspNetCore.App.Ref and Microsoft.AspNetCore.App.Runtime.$(rid) should not be referenced directly...they're not mean to be used as a @nguerrera @dsplaisted - if we merge this to aspnet today, will you be able to make changes to react to this in dotnet/core-sdk? I took a look, and it seems the repo is still using Microsoft.AspNetCore.App to flow dependency updates and find the list of RIDs the aspnetcore runtime supports. cc @sebastienros - benchmarking infrastructure |
Are the sdk changes already in to consume these changes? |
No, that's why I made the previous comment. Not sure if we're expected to
do this or if the SDK team is already on it.
… |
Ah then we shouldn’t stop producing the old shared framework until that’s the case. |
…ing and runtime packs * Stop producing Microsoft.AspNetCore.App, and runtime.$(rid).Microsoft.AspNetCore.App * Generate the shared framework without using 'NuGet' restore * Stop producing intermediate packages for shared-framework only assemblies * Put the platform manifest into the targeting pack (data/Microsoft.AspNetCore.App.PlatformManifest.txt) * Create well-known, shared intermediate directories that installers can use to bundle content
d88ca8e
to
cce50bc
Compare
We will be updating the SDK to consume the updated packages |
I'd like to merge this before master diverges too much from this PR. Got tired of waiting for the SDK, so here you go: dotnet/installer#754 |
@natemcmaster This change is problematic. Do libraries authors build packages that use ASP.NET Core during the 3.0 time frame? This will affect our GRPC development experience if the ref pack can't be used as a substitute. |
Quoting myself from above
Keep using |
@davidfowl Libraries should not have a package dependency on Microsoft.AspNetCore.App. We need NuGet/Home#7342 and https://github.com/dotnet/cli/issues/10666 for packages to be able to declare dependencies on the AspNetCore shared framework. Until then, apps that reference libraries that depend on ASP.NET Core will need to have a direct FrameworkReference to Microsoft.AspNetCore.App. |
I see, libraries just use the FrameworkReference for compile assets and those won't persist. OK. I see that's already the case for GRPC https://www.nuget.org/packages/Grpc.AspNetCore.Server/0.1.19-pre1. |
Aside: GRPC's dependency on Microsoft.NETCore.Platforms is a bug (fixed in preview3) and can lead to downgrades. |
Resolves #6501
This is all about how we build and redistribute aspnetcore. It doesn't change the way users reference aspnetcore.
Changes
cc @nguerrera @dagood @dsplaisted