Replace PackageReference to Microsoft.AspNetCore.App with FrameworkReference

[natemcmaster]

Problem

Most NuGet packages provide both compilation and runtime assets. Microsoft.NETCore.App and Microsoft.AspNetCore.App effectively only provide the first - compilation references. Users must install other runtime assets to make .NET Core apps work but this is not obvious or intuitive, and not always possible: for example, Azure Web Apps, AWS, Google Cloud, etc. This violates a reasonable expectation of using a NuGet package, and has been a continual source of confusion for users.

See #3307 for more context.

Proposed solution

Change the item type used to reference the shared framework in a .csproj file.

<ItemGroup>
   <FrameworkReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>

Unlike PackageReference, a FrameworkReference item:

• May not actually be a NuGet package. (It might be -- but that's an implementation detail hidden from users.)
• There is no Version attribute
• The version of the FrameworkReference is controlled by TargetFramework.

Open questions:

• How does a user specify the runtime patch version? TFMs only include major.minor
• How is FrameworkReference preserved when putting a class library in a NuGet package?
• Are FrameworkReference items transitive across ProjectReference?

Requirements

• Make Microsoft.AspNetCore.App a ref only package (tracked with Make Microsoft.AspNetCore.App a ref-assembly only package #3608)
• Update ASP.NET Core project templates to use FrameworkReference items
• Work with the SDK and tooling team to support this new item type (initial work already done in Support FrameworkReference items sdk#2486)

[natemcmaster]

cc @dsplaisted @nguerrera

[dsplaisted]

There are a lot of work items related to this captured in the following issues (and the issues linked from them):

• Targeting shared frameworks
• Targeting pack support
• Runtime pack support

We're using ZenHub, which you might need to install to see all of the linked issues.

[tomkerkhove]

If FrameworkReference has no version, how do you know what version I want to run?

[poke]

@tomkerkhove It uses whatever shared framework is installed. If you have a .NET Core runtime, then that runtime will contain a matching shared framework for ASP.NET Core, so that’s the version that is being used. If you update your runtime later and get a new shared framework, then that is going to be the framework that is being used. Just like now, the shared framework version is implicitly defined by the runtime and will roll forward for runtime updates.

[tomkerkhove]

Hm but does that mean it no longer uses what is shipped with the app but rather what is installed on the machine and we're moving away from running multiple versions in parallel?

[poke]

The forward rolling behavior already exists with 2.1 and only applies to patch level updates. Nothing will change in that regard. It’s just that the way this actually works will be polished. So instead of a version-less PackageReference to the shared framework, you now have a FrameworkReference. Same idea but better implemented.

[natemcmaster]

does that mean it no longer uses what is shipped with the app but rather what is installed on the machine and we're moving away from running multiple versions in parallel?

No, this is not changing. You can still use multiple .NET core versions side by side.

If FrameworkReference has no version, how do you know what version I want to run?

The version of AspNetCore will be determined from the value of the TargetFramework property. netcoreapp3.0, netcoreapp3.1, netcoreapp4.0, etc.

The rollforward behavior is unaffected by this. This proposal is primarily about how the SDK works, not how the app behaves. See
https://docs.microsoft.com/en-us/dotnet/core/versions/selection#framework-dependent-apps-roll-forward for a detailed explanation of rollforward.

[Sebazzz]

@natemcmaster

The version of AspNetCore will be determined from the value of the TargetFramework property. netcoreapp3.0, netcoreapp3.1, netcoreapp4.0, etc.

I can imagine a case where someone would run AspNetCore 2.0 on .NET Core 2.1. That wouldn't be possible anymore, right?

[natemcmaster]

Correct. Moving forward, you can simply think of ASP.NET Core as being part of .NET Core.

[Nirmal4G]

@natemcmaster @DamianEdwards

Then why not move ASP.NET Core into .NET Core through System.* namespaces?
.NET for WEB can have Server APIs, Hosting APIs (Fundamental Building Blocks for WEB platform) without the ASP.NET specifics.

[Nirmal4G]

Then you can have something like...

Microsoft.NET.Core

platform and shared APIs common to all

Microsoft.NET.Web

Sever-Client APIs, P2P, Hosting, RPC..

Microsoft.NET.IoT

GPIO APIs, std. IoT sensor APIs, device communication protocols, etc..

Microsoft.NET.ML

the current ML.NET and the like

Microsoft.NET.UI

Universal UI elements, XAML, and various shared UI support

Vendor.NET.UI.Form

Form -> TV, Mobile, WorkSpace, Tablet, Wearable, etc...

Vendor.NET.UI.Mobile

Xamarin, UWP, Tizen, Mobile specific controls and platform support

Vendor.NET.UI.Desktop

WPF, WinForms, UWP, Desktop specific controls and platform support

… and so on...!

Ain't that would be a wonderful world of .NET!

[davidfowl]

Then why not move ASP.NET Core into .NET Core through System.* namespaces?
.NET for WEB can have Server APIs, Hosting APIs (Fundamental Building Blocks for WEB platform) without the ASP.NET specifics.

@Nirmal4G that would be a massive breaking change for little benefit.

[Nirmal4G]

@davidfowl That's the whole reason for .NET Core, right? So that you wouldn't have to stop innovating... in this case convergence...!

[Nirmal4G]

Core framework should provide fundamentals for each type of platform that the framework is supporting... this should increase platform & support discovery, and among other things... Many people still not yet aware of .NET being used in ML and IoT space...

We need more like these...

System.Learning (ML.NET)
System.Net.Http.HttpServer (other base communique protocols support)
System.Graphics
System.Devices

[davidfowl]

Not really, we haven't made that many significant breaking changes in ASP.NET Core. The biggest one was the authentication system between 1.0 and 2.0. We wouldn't change the namespace like this, it's just badness. It breaks all libraries and there's extremely little to gain from it.

[Nirmal4G]

Anyway I started this discussion on .NET home repo. We'll continue from there... We're going off-topic on this thread.

[dotnetchris]

Great change