Skip to content
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

Replace PackageReference to Microsoft.AspNetCore.App with FrameworkReference #3612

Closed
natemcmaster opened this issue Oct 11, 2018 · 17 comments

Comments

@natemcmaster
Copy link
Contributor

commented Oct 11, 2018

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 #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 dotnet/sdk#2486)

@natemcmaster natemcmaster added this to the 3.0.0 milestone Oct 11, 2018

@natemcmaster

This comment has been minimized.

Copy link
Contributor Author

commented Oct 11, 2018

@dsplaisted

This comment has been minimized.

Copy link

commented Oct 11, 2018

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

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

@tomkerkhove

This comment has been minimized.

Copy link

commented Oct 30, 2018

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

@poke

This comment has been minimized.

Copy link
Contributor

commented Oct 30, 2018

@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

This comment has been minimized.

Copy link

commented Oct 30, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Oct 30, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Oct 30, 2018

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

This comment has been minimized.

Copy link

commented Nov 2, 2018

@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

This comment has been minimized.

Copy link
Contributor Author

commented Nov 2, 2018

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

@Nirmal4G

This comment has been minimized.

Copy link

commented Nov 3, 2018

@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

This comment has been minimized.

Copy link

commented Nov 3, 2018

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

This comment has been minimized.

Copy link
Member

commented Nov 3, 2018

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

This comment has been minimized.

Copy link

commented Nov 3, 2018

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

@Nirmal4G

This comment has been minimized.

Copy link

commented Nov 3, 2018

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

This comment has been minimized.

Copy link
Member

commented Nov 3, 2018

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

This comment has been minimized.

Copy link

commented Nov 3, 2018

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

@dotnetchris

This comment has been minimized.

Copy link

commented Nov 9, 2018

Great change

@natemcmaster natemcmaster self-assigned this Nov 16, 2018

natemcmaster added a commit to aspnet/Templating that referenced this issue Nov 16, 2018

React to breaking changes in Microsoft.AspNetCore.App (#836)
Changes:

* Add packages references for EF Core, when necessary
* Add packages references for SpaServices to Spa templates
* Remove PackageReference to Microsoft.AspNetCore.App altogether

See aspnet/AspNetCore#3612 for more context
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.