Migrate Microsoft.Extensions packages into their own Framework (and workload)

[AraHaan]

For starters, the Microsoft.Extensions.* packages that are from this repository are great, well known, and also well used (with a majority used by tons of packages that result in a huge dependency chain of just those packages alone if you count the transitive dependencies).

Because of this I would like to suggest making them into an framework named Microsoft.NETCore.Extensions.App framework that can be used for all types of apps, This framework would replace the nuget package versions and support .NET 6 at minimum (or rather the TFM that the packages all commonly support at minimum), also make them into an workload that can be installed into the .NET 7 SDK (not the .NET 6 one).

Other changes that would need to be made:

• Migrate the usage of them in dotnet/aspnetcore (and possibly other repos) to the workload version (An Sdk change would need to be made to make it know about the new workload before then).
• A nuget.org change would need to be made to make it possible to obsolete the Microsoft.Extensions nuget package for that workload so they get warned to "install the workload instead".

Pros of the change:

• the libraries could benefit from crossgen2 for startup performance and various other things that might make them able to be optimized more than what the package version can offer.
• more easier to use and less chance of a dependency version conflict (the updates would flow in when you update the workload and would update for all projects) (less chance of dll hell at runtime too).
• overall the workload experience would be better than the package approach here for these well known packages that can become their own framework (because there are a lot of them that it would be more logical to make it a framework).
• easier to contribute to projects depending on the workload as then it can be listed as an hard requirement to have the workload installed when you open their Visual Studio solution file.

Cons of the change:

• Might not support as many TFMs as the package version (unless there is a way to preserve that one too).
• Would require some help to configure the workload installer generation for this in this repository, however the workload would probably need it's own SDK to insert itself into KnownFrameworkReference and define a property responsible for enabling the insertion and framework reference.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[teo-tsirpanis]

The packages in the Microsoft.Extensions family are plain-old general-purpose libraries. They need no special SDK support to warrant their own workload. And they also have to support .NET Framework through .NET Standard 2.0, so obsoleting the NuGet cannot happen.

[AraHaan]

Hmm I guess the framework option could work for .NET Standard based frameworks (like .NET Framework for example) right?

Or is FrameworkReference not possible for sdk style .NET Framework projects?
Although the users might not be using sdk style though 🤔.

I guess the deprecation message could be added to the .NET SDK when it sees them referencing the packages in .NET 6+ to use the workload instead.

[teo-tsirpanis]

I still don't understand why to make them on their own shared framework. Extensions is a library, not an app model like ASP.NET Core, Windows Desktop or MAUI. Imagine needing a shared framework for Newtonsoft.Json.

[AraHaan]

Newtonsoft is a single package, Extensions is not (and is often considered by many it's own framework because of that).

[teo-tsirpanis]

That is a miconception. Extensions is like the Windows Community Toolkit. A set of libraries that could have well resided in the BCL or in a third-party library. There's absolutely nothing special about them.

[AraHaan]

While that may be the case, take a look at the ASP.NET Core framework reference, almost (if not all of them) are included in it, however they could have been instead moved to their own framework that one would have to opt-into using (with asp.net core projects opting into it by default). Because of that many people thought it was a great idea to try to manually reference the ASP.NET Core framework when using:

• WindowsDesktop
• MAUI

However it would then result in failure to run the program due to that (because they want the extensions to be used from a framework and not from a package because their application is FDD and not self-contained) with it thinking that the relevant runtime is not installed (WindowsDesktop/MAUI).

That was one of the main reasons for filing the issue, along with the reasons I listed above like enabling crossgen2 on all the Microsoft.Extensions assemblies that are inside the reference to boost statup performance (which can also indirectly improve asp.net core / efcore as well).

And yes my argument is, if asp.net core apps can use them in FDD without needing the packages, so should any other type of project if they opt-in to not using the packages but still be able to use them the same way asp.net core apps can (also doing such could bring down the size of the asp.net core framework itself by at least 3~5 MB or so by having the source code to that framework also opt-in to it, it's planned to be a workload anyway so why cant workloads depend on other workloads?).

Also I forgot 1 other reason as well:

• Imagine a security issue existed in an Microsoft.Extensions.* library, with the package being referenced. A typical developer might not be aware of said issue and might skip the update thinking that it might not affect their project, likewise if the project was already compiled with the package they will not get the patch to automatically be applied when they run the application.
  • This would not be an issue if the workload existed as it would be easy to let the developer know "hey update this workload to this security patch." and then when they run the FDD application it will use that patch (without being forced to update the package themselves, recompile, and pray the updated dll was copied).

Tagging subscribers to this area: @dotnet/area-meta
See info in area-owners.md if you want to be subscribed.

Issue Details

---

For starters, the Microsoft.Extensions.* packages that are from this repository are great, well known, and also well used (with a majority used by tons of packages that result in a huge dependency chain of just those packages alone if you count the transitive dependencies).

Because of this I would like to suggest making them into an framework named Microsoft.NETCore.Extensions.App framework that can be used for all types of apps, This framework would replace the nuget package versions and support .NET 6 at minimum (or rather the TFM that the packages all commonly support at minimum), also make them into an workload that can be installed into the .NET 7 SDK (not the .NET 6 one).

Other changes that would need to be made:

• Migrate the usage of them in dotnet/aspnetcore (and possibly other repos) to the workload version (An Sdk change would need to be made to make it know about the new workload before then).
• A nuget.org change would need to be made to make it possible to obsolete the Microsoft.Extensions nuget package for that workload so they get warned to "install the workload instead".

Pros of the change:

• the libraries could benefit from crossgen2 for startup performance and various other things that might make them able to be optimized more than what the package version can offer.
• more easier to use and less chance of a dependency version conflict (the updates would flow in when you update the workload and would update for all projects) (less chance of dll hell at runtime too).
• overall the workload experience would be better than the package approach here for these well known packages that can become their own framework (because there are a lot of them that it would be more logical to make it a framework).
• easier to contribute to projects depending on the workload as then it can be listed as an hard requirement to have the workload installed when you open their Visual Studio solution file.

Cons of the change:

• Might not support as many TFMs as the package version (unless there is a way to preserve that one too).
• Would require some help to configure the workload installer generation for this in this repository, however the workload would probably need it's own SDK to insert itself into KnownFrameworkReference and define a property responsible for enabling the insertion and framework reference.

Author:	AraHaan
Assignees:	-
Labels:	area-Meta, packaging, untriaged
Milestone:	-

Tagging subscribers to this area: @dotnet/area-extensions-primitives
See info in area-owners.md if you want to be subscribed.

Issue Details

---

For starters, the Microsoft.Extensions.* packages that are from this repository are great, well known, and also well used (with a majority used by tons of packages that result in a huge dependency chain of just those packages alone if you count the transitive dependencies).

Because of this I would like to suggest making them into an framework named Microsoft.NETCore.Extensions.App framework that can be used for all types of apps, This framework would replace the nuget package versions and support .NET 6 at minimum (or rather the TFM that the packages all commonly support at minimum), also make them into an workload that can be installed into the .NET 7 SDK (not the .NET 6 one).

Other changes that would need to be made:

• Migrate the usage of them in dotnet/aspnetcore (and possibly other repos) to the workload version (An Sdk change would need to be made to make it know about the new workload before then).
• A nuget.org change would need to be made to make it possible to obsolete the Microsoft.Extensions nuget package for that workload so they get warned to "install the workload instead".

Pros of the change:

• the libraries could benefit from crossgen2 for startup performance and various other things that might make them able to be optimized more than what the package version can offer.
• more easier to use and less chance of a dependency version conflict (the updates would flow in when you update the workload and would update for all projects) (less chance of dll hell at runtime too).
• overall the workload experience would be better than the package approach here for these well known packages that can become their own framework (because there are a lot of them that it would be more logical to make it a framework).
• easier to contribute to projects depending on the workload as then it can be listed as an hard requirement to have the workload installed when you open their Visual Studio solution file.

Cons of the change:

• Might not support as many TFMs as the package version (unless there is a way to preserve that one too).
• Would require some help to configure the workload installer generation for this in this repository, however the workload would probably need it's own SDK to insert itself into KnownFrameworkReference and define a property responsible for enabling the insertion and framework reference.

Author:	AraHaan
Assignees:	-
Labels:	untriaged, area-Extensions-Primitives
Milestone:	-