Deprecate the Microsoft.AspNetCore.App metapackage in favor of targeting and runtime packs

[natemcmaster]

Resolves #6501

This is all about how we build and redistribute aspnetcore. It doesn't change the way users reference aspnetcore.

Changes

• Stop producing Microsoft.AspNetCore.App, and runtime.$(rid).Microsoft.AspNetCore.App
• Generate the shared framework without using 'NuGet' restore
• Put the platform manifest into the targeting pack (data/Microsoft.AspNetCore.App.PlatformManifest.txt)
• Removes the need to generate packages so we can figure out what belongs in the shared framework
• Create well-known, shared intermediate directories that installers can use to bundle content

cc @nguerrera @dagood @dsplaisted

[dsplaisted]

We need to do https://github.com/dotnet/cli/issues/10442 before you stop producing the runtime.$(rid).Microsoft.AspNetCore.App packages

[natemcmaster]

I see https://github.com/dotnet/cli/issues/10442 is marked as <blocked>. Do you have a rough ETA?

[nguerrera]

I think the blocked was because we didn't have the new packages so that is now unblocked. Also, we don't need the file list to unblock this because we kept nuget folder conventions.

[natemcmaster]

we don't need the file list

Which file list, the platform manifest?

[dougbu]

One bit is confusing me but, otherwise (once unblocked and builds pass),

[pakrym]

cc @anurse

[natemcmaster]

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 <PackageReference>. Instead, consumers should use <FrameworkReference>.

@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

[davidfowl]

Are the sdk changes already in to consume these changes?

[natemcmaster]

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.

…

[davidfowl]

Ah then we shouldn’t stop producing the old shared framework until that’s the case.

[dsplaisted]

Not sure if we're expected to do this or if the SDK team is already on it.

We will be updating the SDK to consume the updated packages

[natemcmaster]

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

[davidfowl]

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

[natemcmaster]

Quoting myself from above

This is all about how we build and redistribute aspnetcore. It doesn't change the way users reference aspnetcore.

Keep using <FrameworkReference>

[dsplaisted]

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

[davidfowl]

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.

[nguerrera]

Aside: GRPC's dependency on Microsoft.NETCore.Platforms is a bug (fixed in preview3) and can lead to downgrades.