Proposal: Packages for shared framework assemblies in 3.0

[CodeTherapist]

Discussion for issues: #3757, #3756 and aspnet/Announcements/326,

Unfortunately I didn't see any of those issues and wasn't aware of that breaking change - otherwise I had commented on the original discussion issue.

Before I start explaining my proposal, I want to ensure that everyone is aware that I like in general how the whole .NET ecosystem is going forward and it's a great time to be a .NET developer 😃 🎉

In general I agree on the arguments of @davidfowl (on the original issue):

That gives the illusion that they are indeed usable as individual packages. When they eventually will land in an application that is shipping all of these components together on a specific ship cycle.
We don't test newer versions of ASP.NET Core on older versions of .NET Core
We don't test mixing and matching versions of the various ASP.NET Core packages versions
This change makes that a bit more clear that ASP.NET Core is indeed a unit that ships together and isn't meant to be used peacemeal (at least these core pieces).

Because it's aligned with the following principles:

Common closure principle (CCP)
Gather into the framework those packages that change for the same reasons and at the same times. Separate into different frameworks/packages that change at different times and reasons.

Release equivalence principle (REP)
Classes and packages that are grouped together into a framework should be releasable together. The fact that they share the same version number and the same release cycle, should make sense to the developers that different versions can't be mixed.

However, bundling the ASP.NET Core framework (platform) into the .NET Core (SDK) is violating both of them: The CCP is violated because a change to the .NET Core (SDK) means also a release of the ASP.NET Core framework and vice versa. The REP is violated because both could be released independently in different release cycles.

My proposal is not fundamentally different from the original idea.
A csproj for a ASP.NET Core application would look the same:

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <OutputType>WinExe</OutputType>
  </PropertyGroup>
  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" Version="3.0.0" />
  </ItemGroup>
</Project>

The main difference is that the FrameworkReference would be a nuget package (similiar to the meta-nuget-package) with all other packages in it, that makes that framework.

To be clear:
There are no loosely nuget packages shipped (e.g. Microsoft.AspNetCore.Mvc.Core doesn't exist). This would address the concerns of mixing versions and is aligned with the intension of the original change.

Library authors (or advanced application developers) could selectively reference dependencies to express on what they depend exactly:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <OutputType>WinExe</OutputType>
  </PropertyGroup>
  <ItemGroup>
    <FrameworkReference Include="Microsoft.AspNetCore.App" Version="3.0.0">
           <Dependency Include="Microsoft.AspNetCore.Mvc.Abstractions" />
    </FrameworkReference>
  </ItemGroup>
</Project>

The sub-element are individual packages in that particular framework (nuget) package.
No Version="..." attribute is allowed on the <Dependency> node - it is strongly coupled on the parent <FrameworkReference>.

Updating my library to work with a newer framework is straight forward by updating the Version attribute and do a nuget restore (as we do today):

<FrameworkReference Include="Microsoft.AspNetCore.App" Version="3.1.0" />

Other projects that would reference this library needs a framework dependency to the same version.

Benefits of this proposal

• Nuget would be still the primary source of truth for our dependencies (why do we need an exception?)
• No need to download a new dotnet when I wish to update my fancy library to a newer ASP.NET Core.
• Closer to the system that we used to (since .NET Core 1.0)
• No possibility to mix versions of packages that should be consumed together
• .NET Core (SDK) and ASP.NET Core can be shipped independently

Closing

Maybe I'm totally wrong with my idea or I didn't got the big picture. Please let me know when you think my proposal is bad or not feasible at all. That said, I'm not an expert in every detail of the .NET Core / ASP.NET Core ecosystem. I appreciate any additional idea, detail explanations and contributions. Always happy to learn everyday 👍

[davidfowl]

I can tell you we're not going to fundamentally change anything this late in the release cycle but here's my feedback regardless.

Nuget would be still the primary source of truth for our dependencies (why do we need an exception?)

It's not clear exactly what this means. Framework references are expressed in the nuspec. Are you talking about acquisition?

No need to download a new dotnet when I wish to update my fancy library to a newer ASP.NET Core.

This is a benefit but are you ok downloading a new dotnet when you need a new version of the framework itself? Why is ASP.NET Core any different?

Closer to the system that we used to (since .NET Core 1.0)

We explicitly do not want that.

No possibility to mix versions of packages that should be consumed together

👍

.NET Core (SDK) and ASP.NET Core can be shipped independently

We don't plan to do this.

[CodeTherapist]

I can tell you we're not going to fundamentally change anything this late in the release cycle but here's my feedback regardless.

I understand this - never meant to change anything right now at this stage.
Thank you for your answers and time 😃 👍

Nuget would be still the primary source of truth for our dependencies (why do we need an exception?)

It's not clear exactly what this means. Framework references are expressed in the nuspec. Are you talking about acquisition?

Yes, I'm mainly talking about acquisition.

No need to download a new dotnet when I wish to update my fancy library to a newer ASP.NET Core.

This is a benefit but are you ok downloading a new dotnet when you need a new version of the framework itself? Why is ASP.NET Core any different?

I would like to have the .NET Core framework the same way: also not to included into the SDK as well, but I thought that there are some technical restrictions and is not possible(?). Further the .NET Core itself is the base of all application-models that .NET supports which makes it special.

ASP.NET Core is a specific application-model. When ASP.NET Core is included, then I would expect that all other application-models like Winforms, WPF and Azure (e.g. Microsoft.Azure.Storage.Common) would treated the same way. Otherwise, why are the other app-models not suitable to be part of the shared framework as well (or is that planed)?

This feels like the "Full .NET Framework" that we have today - except that we can install side by side for the common scenarios to avoid break another app installed on the same machine.

Closer to the system that we used to (since .NET Core 1.0)

We explicitly do not want that.

Why?
I'm sure, that one of the reason of the success of ASP.NET Core (and .NET Core) originated exactly from that fundamental idea what the ASP.NET Core framework should be. I'm confident, that I'm not alone with this opinion.

[davidfowl]

ASP.NET Core is a specific application-model. When ASP.NET Core is included, then I would expect that all other application-models like Winforms, WPF and Azure (e.g. Microsoft.Azure.Storage.Common) would treated the same way. Otherwise, why are the other app-models not suitable to be part of the shared framework as well (or is that planed)?

Azure is not an application model and the other frameworks are included when you download .NET Core (on windows). It comes with WPF, Winforms and ASP.NET Core. The reason you get it by default is because when you specify the <Project Sdk="Microsoft.NET.Sdk.Web"> aka the websdk, we automatically include the FrameworkReference to ASP.NET Core.

Why?
I'm sure, that one of the reason of the success of ASP.NET Core (and .NET Core) originated exactly from that fundamental idea what the ASP.NET Core framework should be. I'm confident, that I'm not alone with this opinion.

We depend on core runtime features and the value in being able to ship separately is extremely low in practice. We ship .NET Core as a wholistic product and have actually been doing so for years now (since 1.0). The underlying tech is decoupled enough to change this and this is a product decision not a technical one.

[ghost]

Thank you for contacting us. Due to a lack of activity on this discussion issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.

This issue will be locked after 30 more days of inactivity. If you still wish to discuss this subject after then, please create a new issue!