Aspnetcore: Stop producing packages for shared framework assemblies in 3.0

[natemcmaster]

:bulb: _Working draft: this list will may fluctuate as we continue to work on ASP.NET Core 3.0._

In ASP.NET Core 3.0, we plan to stop producing the following NuGet packages. We're doing this because we packages should be unnecessary as a result of https://github.com/aspnet/AspNetCore/issues/3608, https://github.com/aspnet/AspNetCore/issues/3610, and https://github.com/aspnet/AspNetCore/issues/3753

The API for these packages will still be available, and will be part of Microsoft.AspNetCore.App.
Projects which use these API should replace the <PackageReference> with a <FrameworkReference> to Microsoft.AspNetCore.App. (see #3612 )

• Microsoft.AspNetCore
• Microsoft.AspNetCore.Antiforgery
• Microsoft.AspNetCore.Authentication
• Microsoft.AspNetCore.Authentication.Abstractions
• Microsoft.AspNetCore.Authentication.Cookies
• Microsoft.AspNetCore.Authentication.Core
• Microsoft.AspNetCore.Authentication.JwtBearer
• Microsoft.AspNetCore.Authentication.OAuth
• Microsoft.AspNetCore.Authentication.OpenIdConnect
• Microsoft.AspNetCore.Authorization
• Microsoft.AspNetCore.Authorization.Policy
• Microsoft.AspNetCore.CookiePolicy
• Microsoft.AspNetCore.Cors
• Microsoft.AspNetCore.Cryptography.Internal
• Microsoft.AspNetCore.Cryptography.KeyDerivation
• Microsoft.AspNetCore.DataProtection
• Microsoft.AspNetCore.DataProtection.Abstractions
• Microsoft.AspNetCore.DataProtection.Extensions
• Microsoft.AspNetCore.Diagnostics
• Microsoft.AspNetCore.Diagnostics.HealthChecks
• Microsoft.AspNetCore.HostFiltering
• Microsoft.AspNetCore.Hosting
• Microsoft.AspNetCore.Hosting.Abstractions
• Microsoft.AspNetCore.Hosting.Server.Abstractions
• Microsoft.AspNetCore.Http
• Microsoft.AspNetCore.Http.Abstractions
• Microsoft.AspNetCore.Http.Connections
• Microsoft.AspNetCore.Http.Extensions
• Microsoft.AspNetCore.Http.Features
• Microsoft.AspNetCore.HttpOverrides
• Microsoft.AspNetCore.HttpsPolicy
• Microsoft.AspNetCore.Identity
• Microsoft.AspNetCore.Localization
• Microsoft.AspNetCore.Localization.Routing
• Microsoft.AspNetCore.MiddlewareAnalysis
• Microsoft.AspNetCore.Mvc
• Microsoft.AspNetCore.Mvc.Abstractions
• Microsoft.AspNetCore.Mvc.ApiExplorer
• Microsoft.AspNetCore.Mvc.Core
• Microsoft.AspNetCore.Mvc.Cors
• Microsoft.AspNetCore.Mvc.DataAnnotations
• Microsoft.AspNetCore.Mvc.Formatters.Json
• Microsoft.AspNetCore.Mvc.Formatters.Xml
• Microsoft.AspNetCore.Mvc.Localization
• Microsoft.AspNetCore.Mvc.Razor
• Microsoft.AspNetCore.Mvc.Razor.Extensions
• Microsoft.AspNetCore.Mvc.Razor.ViewCompilation
• Microsoft.AspNetCore.Mvc.RazorPages
• Microsoft.AspNetCore.Mvc.TagHelpers
• Microsoft.AspNetCore.Mvc.ViewFeatures
• Microsoft.AspNetCore.ResponseCaching
• Microsoft.AspNetCore.ResponseCaching.Abstractions
• Microsoft.AspNetCore.ResponseCompression
• Microsoft.AspNetCore.Rewrite
• Microsoft.AspNetCore.Routing
• Microsoft.AspNetCore.Routing.Abstractions
• Microsoft.AspNetCore.Server.HttpSys
• Microsoft.AspNetCore.Server.IIS
• Microsoft.AspNetCore.Server.IISIntegration
• Microsoft.AspNetCore.Server.Kestrel
• Microsoft.AspNetCore.Server.Kestrel.Core
• Microsoft.AspNetCore.Server.Kestrel.Https
• Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions
• Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets
• Microsoft.AspNetCore.Session
• Microsoft.AspNetCore.SignalR
• Microsoft.AspNetCore.SignalR.Core
• Microsoft.AspNetCore.StaticFiles
• Microsoft.AspNetCore.WebSockets

Under consideration

We are considering whether the following provide enough utility outside of server scenarios to continue existing as packages. Consider this issue open for comments on this:

• Microsoft.AspNetCore.Razor
• Microsoft.AspNetCore.Razor.Runtime
• Microsoft.AspNetCore.WebUtilities
• Microsoft.Net.Http.Headers

[poke]

Does this mean that libraries for ASP.NET Core will then also have to reference the shared framework, instead of being able to reference just the dependencies they need? I assume this also means that you cannot produce these as netstandard libraries anymore then?

[natemcmaster]

Does this mean that libraries for ASP.NET Core will then also have to reference the shared framework, instead of being able to reference just the dependencies they need?

Yes. The SDK and NuGet teams are still working on the details of how <FrameworkReference> works in class library projects and how this round-trips in a NuGet package. Details on this are still being worked out.

I assume this also means that you cannot produce these as netstandard libraries anymore then?

Correct. We are removing the netstandard2.0 from most Microsoft.AspNetCore.* assemblies. See #3754

[jchannon]

My understanding is a bit hazy but what does this also mean for people who publish their apps as standalone applications? If the libraries they use depend on the shared fwk then is standalone not possible any more?

[poke]

@jchannon That’s what self-contained deployments are for. That way, you bundle the runtime when publishing your application, so you are independent from the installed runtime.

[mpp-owainc]

I'm a little disheartened by this; myself and others (from comments on the other issue) make use of many of these packages as they are a great corpus of solid features and implementations 'off-the-shelf'. Tying them to a 50MB+ runtime dependency via <FrameworkReference> is a huge step backwards and a real loss to the nuget ecosystem.

Hopefully some middle ground can be found that will allow specific functionality to continue to exist and develop independently without being tied to the monolithic framework - perhaps by publishing under different package/assembly names?

I understand some of the reasoning but if we have to copy/paste code in order to access functionality without the huge runtime dependency we've basically gone back to the "look but don't touch" shared source of the .NET Framework, and [I hope] nobody wants that.

[davidfowl]

@owainc so you’re main concern is about deployment size? Today you’re using packages to minimize the dependencies?

Is there something else?

[mpp-owainc]

@davidfowl Mostly yes, not all dotnetcore apps are ASP.NET, and in an age of containers the idea of "shared frameworks" is a bit of an odd one. There's slightly more though...

Having the packages as bite-size libraries allows a person to download, inspect, modify, deploy within a reasonable amount of time - it is a nice "in" for outsiders to get into framework code. If it were a embedded within a monolith repository (and I'm speculating a bit here...) that just might not be an option for many reasons.

[HKochniss]

Hrm I get that you guys saw all the issues and pain with shared framework deps vs. handauthored csproj package references, and the AWS Lambda guys etc. having issues.
I think there is a middleground missing, call it "expert mode", where I can still reference a specific sub assembly w/o a shared framework, and not rely on you guys to factor out stuff that a larger population cried loud enough about splitting out.. would only be used in rare cases.

Couldn't there be at least a sideway "compile-it-in" support via shared source package references (https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files?WT.mc_id=-blog-scottha#controlling-dependency-assets) ?

[Tratcher]

@owainc Very few packages are islands, most drag in a chain of dependencies. This is especially true for anything ASP.NET Core related. E.g. if you use just MVC and Kestrel that pulls in more than half of the packages listed above. From that list I think only Microsoft.AspNetCore.WebUtilities could actually be used without pulling in at least 5 of the other packages (which is an argument for moving it to Extensions).

Any specific examples of pieces you'd use independently?

[natemcmaster]

Tying them to a 50MB+ runtime dependency via is a huge step backwards and a real loss to the nuget ecosystem.

FYI - my latest prototype of Microsoft.AspNetCore.App 3.0 clocks in at 20.6 MB, and Microsoft.NETCore.App is about 66 MB. Total size for self-contained is 86.6 MB plus whatever you add to the base set.

what does this also mean for people who publish their apps as standalone applications?

Self-contained deployment will continue to be supported. This issue tracks some packaging work we have to do to keep this working: https://github.com/aspnet/AspNetCore/issues/3607

Hopefully some middle ground can be found that will allow specific functionality to continue to exist and develop independently without being tied to the monolithic framework - perhaps by publishing under different package/assembly names?

This is not currently something we're considering. We made this choice after years of discussing the tradeoffs of small component vs larger frameworks. ASP.NET Core 1.x and 2.x shipped as bite-sized libraries, but that came with its own set of issues. Customers reported difficulty understanding which versions of components were actually in use, identifying when their app was vulnerable to security bugs and if they had updated correctly or not. It contributed to slower build performance, large offline package caches, slower restore times for those without the cache, etc. On our end, it was impossible to test all possible version combinations of our 200+ packages and ensure various pieces of the framework function correctly together.

We're pivoting towards treating Microsoft.AspNetCore.App as the fundamental unit of "ASP.NET Core", and we believe the unification addresses many of the problems. I acknowledge one of the tradeoffs we're making here is that you won't have access to as many bite-sized libraries. There will still be some; Microsoft.Extensions.*, the SignalR client, and possibly a few other Microsoft.AspNetCore.* libraries which are generally useful on many platforms (as @Tratcher mentioned, Microsoft.AspNetCore.WebUtilities is under consideration). The other notable tradeoff is deployment size; if you want aspnetcore, you get all of Microsoft.AspNetCore.App (current prototype is 20 MB).

The shared framework provides enough benefits that we decided to make it the default experience for users in 2.1. So far, the complaints I have seen are about versioning and <PackageReference>, which I believe our 3.0 plans will resolve. There are other benefits of the shared framework which, so far, users seem happy with. Servicing is simplified to installing the latest patch on the machine, no need to recompile the app or much with a complicated NuGet restore graph. The versioning easier to understand since it has a single pivot, the version of Microsoft.AspNetCore.App. The shared framework also provides optimizations like ReadyToRun, and lets you take advantage of our Docker images which pre-bundle Microsoft.AspNetCore.App. It's a win for server environments, too, because they have fewer duplicate copies of Microsoft.AspNetCore.*.dll files.

I'm a little disheartened by this

Stick with us. We're announcing these plans early so we have time to iterate and gather feedback. 3.0 isn't even ready for it's first preview. In fact, we're still not done with 2.2. We've got a long road ahead of us and this plan is subject to change.

[jchannon]

Do you not think this will just end up with System.Web all over again and
if you don’t why not?

On Tue, 30 Oct 2018 at 16:48, Nate McMaster [e-mail]
wrote:

Tying them to a 50MB+ runtime dependency via is a huge step backwards and
a real loss to the nuget ecosystem.

FYI - my latest prototype of Microsoft.AspNetCore.App 3.0 clocks in at
20.6 MB, and Microsoft.NETCore.App is about 66 MB. Total size for
self-contained is 86.6 MB plus whatever you add to the base set.

what does this also mean for people who publish their apps as standalone
applications?

Self-contained deployment will continue to be supported. This issue tracks
some packaging work we have to do to keep this working: #3607
https://github.com/aspnet/AspNetCore/issues/3607

Hopefully some middle ground can be found that will allow specific
functionality to continue to exist and develop independently without being
tied to the monolithic framework - perhaps by publishing under different
package/assembly names?

This is not currently something we're considering. We made this choice
after years of discussing the tradeoffs of small component vs larger
frameworks. ASP.NET Core 1.x and 2.x shipped as bite-sized libraries, but
that came with its own set of issues. Customers reported difficulty
understanding which versions of components were actually in use,
identifying when their app was vulnerable to security bugs and if they had
updated correctly or not. It contributed to slower build performance, large
offline package caches, slower restore times for those without the cache,
etc. On our end, it was impossible to test all possible version
combinations of our 200+ packages and ensure various pieces of the
framework function correctly together.

We're pivoting towards treating Microsoft.AspNetCore.App as the
fundamental unit of "ASP.NET Core", and we believe the unification
addresses many of the problems. I acknowledge one of the tradeoffs we're
making here is that you won't have access to as many bite-sized libraries.
There will still be some; Microsoft.Extensions., the SignalR client, and
possibly a few other Microsoft.AspNetCore. libraries which are generally
useful on many platforms (as @Tratcher https://github.com/Tratcher
mentioned, Microsoft.AspNetCore.WebUtilities is under consideration). The
other notable tradeoff is deployment size; if you want aspnetcore, you get
all of Microsoft.AspNetCore.App (current prototype is 20 MB).

The shared framework provides enough benefits that we decided to make it
the default experience for users in 2.1. So far, the complaints I have seen
are about versioning and , which I believe our 3.0
plans will resolve. There are other benefits of the shared framework which,
so far, users seem happy with. Servicing is simplified to installing the
latest patch on the machine, no need to recompile the app or much with a
complicated NuGet restore graph. The versioning easier to understand since
it has a single pivot, the version of Microsoft.AspNetCore.App. The shared
framework also provides optimizations like ReadyToRun, and lets you take
advantage of our Docker images which pre-bundle Microsoft.AspNetCore.App.
It's a win for server environments, too, because they have fewer duplicate
copies of Microsoft.AspNetCore.*.dll files.

I'm a little disheartened by this

Stick with us. We're announcing these plans early so we have time to
iterate and gather feedback. 3.0 isn't even ready for it's first preview.
In fact, we're still not done with 2.2. We've got a long road ahead of us
and this plan is subject to change.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/AspNetCore/issues/3756#issuecomment-434378112,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGapnZWeUTL2cUUZ7XlIol-zucs3KxWks5uqILQgaJpZM4YAssQ
.

[daveaglick]

Thank you for continuing to discuss these plans patiently and with detail @natemcmaster. Your comments in this issue and others are tempering what might have been a full-blown panic mode (at least by me). I’m not nearly as concerned now as when the announcements were first made.

[natemcmaster]

Do you not think this will just end up with System.Web all over again and if you don’t why not?

There are 1000 aspects of aspnetcore and System.Web we could compare. Did you have any particular that you're concerned about?

Your comments in this issue and others are tempering what might have been a full-blown panic mode (at least by me).

😄 happy to help.

[Genbox]

@natemcmaster

FYI - my latest prototype of Microsoft.AspNetCore.App 3.0 clocks in at 20.6 MB, and Microsoft.NETCore.App is about 66 MB. Total size for self-contained is 86.6 MB plus whatever you add to the base set.

Do those numbers seem reasonable to you? In order to write "Hello World" to the console, you need 86 MB of compiled blob to accompany it.

I just setup 3 self-contained versions of a "hello world" application:

• .NET Core 1.0: 20 MB - Non-crossgen'd code
• .NET Core 2.0: 64 MB - Due to crossgen and a bunch of useless dependencies
• .NET Core 2.1: 72 MB - More useless assemblies...

My company started using .NET Core 1.0.0 when it was in preview and we were thrilled to get a more lightweight framework without all the built-up cruft .NET Framework had over the years. Then MS decided to crossgen out of the blue... then they added more assemblies we didn't need, and then they finally decided to deprecate all older versions and force us to use 2.1 (because they didn't want to fix critical bugs in previous versions).

Our application is extremely size sensitive and we don't care about startup performance or shaving seconds off our builds with a tighter dependency graph. To us, every single megabyte counts.

I know my example is not ASP.net Core related, but it serves as an example where release notes for newer versions always said: "better, more flexible and faster!". I bet you the next step is to cross-gen ASP.net Core assemblies, and then you are up to 40 MB. Then you decide to add dependency X, Y and Z because "We need it. It makes it easier." and then we are up to 80 MB. 3 years later everyone is talking about why a blank controller and view in Razor needs 200 MB runtime, 140 MB more than the whole Linux kernel + drivers + GNU subsystem and C runtime.

So for the love of God, please add some options to enable developers to tweak the ecosystem to their needs. A couple of switches to dotnet publish or options in the csproj file goes a long way.

[natemcmaster]

@Genbox this particular request is off topic. This issue is about Microsoft.AspNetCore.App and what we plan to distribute as packages in 3.0. https://github.com/dotnet/core is a better place to ask for options to eliminate crossgen and reduce the size of .NET Core overall. Some options already exist or are an under development, such as https://github.com/dotnet/announcements/issues/30.

[cortex93]

How can Microsoft.AspNetCore.Server.HttpSys, Microsoft.AspNetCore.Server.IIS, Microsoft.AspNetCore.Server.IISIntegration be part of a cross platform shared framework ?

Could Kestrel be part of its own "framework" as a standalone http server ? asp.net core MVC should be an option and not imposed as a de facto.

[davidfowl]

Microsoft.AspNetCore.Server.HttpSys, Microsoft.AspNetCore.Server.IIS, Microsoft.AspNetCore.Server.IISIntegration be part of a cross platform shared framework ?

We have some windows specific components that light up when configured. They could absolutely be removed but IIS support is still very first class and we’d like to keep supporting an out of the box experience there. I could see us leaving http.sys as a package but there’s no benefit to doing so as it just depends on the OS.

Could Kestrel be part of its own "framework" as a standalone http server

Yes but it’s not factored that way right now. It may be in a future release. St the moment kestrel is pretty tied to asp.net core at the moment.

asp.net core MVC should be an option and not imposed as a de facto.

MVC is not being removed. Being able to build APIs and web applications is a core experience and MVC is what we currently ship that accomplishes that.

[dustinmoris]

I'm not sure whether I like this change or not, but I do feel like this change is being decided prematurely. We had years of a massive framework and only very little time with the NuGet model and the customer complaints to me sound more like a gap in education which would come with time and an issue which could be easily solved with good documentation and tooling. Moving back to a large framework model feels like throwing away all these good intentions of bite sized packages a little too early but maybe I'm worng.

Let's not forget that the future of the web (currently) seems to be containerization and serverless architecture, which I think would both fit more with a bite sized NuGet model, but I'd be keen to hear any counter arguments.

[davidfowl]

@dustinmoris which part don't you like? The fact that we wouldn't have packages for the things listed above? How big do you think those assemblies are that they are problematic in containers? Most of them are tiny and honestly don't move the needle when it comes to container size.

[dustinmoris]

@davidfowl I didn't say that I don't like something (yet) :). If I understand it correctly the change which you propose means the following:

• The majority of .NET Core NuGet packages remain independent as they are?
• We are only talking about ASP.NET Core NuGet packages, which not all but many will be merged into a framework which will come pre-installed with .NET Core?
• With .NET Core 3.0 and going forward an application or library which needs something from ASP.NET Core doesn't have to reference NuGet packages anymore (except a few exceptions) and can just reference an existing framework (similar to .NET 4.x)?

To be honest, I agree that it probably doesn't make sense to split ASP.NET Core into 100 small packages, because mostly you either need at least 50 of them or none (making up numbers here). If I understand it correctly then it also wouldn't affect most libraries which currently reference an ASP.NET Core package, because these libraries are presumably supposed to run from an ASP.NET Core application then anyways, correct? Taking this recent NuGet package as an example, it only references Microsoft.AspNetCore.Http.Abstractions and Microsoft.AspNetCore.Http.Extensions and after .NET Core 3.0 I would replace both references with a framework reference which means my NuGet packge would be smaller in size too?

Now the only potential issue I see is that I've got the feeling that there is a lot of really useful functionality embedded in some Microsoft.AspNetCore.xxx packages which theoretically has no direct relation to ASP.NET Core, but has been implemented there during the .NET Core 1.0 times when the main focus was ASP.NET. Now library authors who were wanting to use some of that functionality in a netstandard library which is not intended to be for ASP.NET Core will lose that ability, correct?

I think overall I think this change probably makes sense if I understood it correctly. Personally I would still like to see that this new ASP.NET Core framework (which comes with .NET Core) will be kept as small as possible. For example things like Razor, MVC, Identity and IIS integration, etc. could still be kept as optional NuGet packages. Maybe just merge several MVC packages into one, etc., but keep the framework footprint small and mainly vanilla ASP.NET Core focused, so that people like me who don't necessarily use MVC as a web framework and don't run Kestrel behind IIS don't have that baggage in our containers.

I understand that the actual disk size is rather small, but once you pull in these things into the framework who knows where it will grow into the future. Also I think it helps library authors to mentally detach themselves from an all or nothing approach to writing useful functionality. For example today MVC is positioned in such a way that most library authors only care (or maybe don't even realise) that a lot of the cool features which they write could be achieved in a framework agnostic way (using more middleware rather than MVC filters for example) so that it becomes more useful across the board. Currently this doesn't always happen which is a bit of a shame. I am a really huge fan of ASP.NET Core and just want to make sure that we keep the ethos and mentality really open and flexible and make it a fantastic choice for more than just C# MVC developers (not because MVC isn't cool, but because more is better :)).

[natemcmaster]

For 3.0.0 preview1, we have removed most packages from shipping, except as noted below.
We plan to revisit this for preview2 as we gather more feedback on which APIs customers want to use in non-shared framework scenarios.

https://github.com/aspnet/AspNetCore/blob/0295f536ef31c0665dd2af9b901b46a6a96ec871/build/SharedFrameworkOnly.props#L10-L20

[CESARDELATORRE]

@natemcmaster @davidfowl Is Microsoft.Extensions.DependencyInjection library still going to be in a different package that ASP.NET Core 3.0? In Extensions.
I don’t think it should be only in ASP.NET Core since you could want to use it only for other lighter types of .NET apps which are not ASP.NET Core. Today, it even works on .NET Framework, which is very convenient for some apps that are not ASP.NET Core.

[natemcmaster]

Yes, most Microsoft.Extensions.* libraries will continue to ship as a normal nuget packages.

[joeaudette]

I have a pagination library that is currently netstandard2.0 https://github.com/cloudscribe/cloudscribe.Web.Pagination
it has dependencies like this:

<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.1.3" />
<PackageReference Include="Microsoft.AspNetCore.Mvc.Core" Version="2.1.3" />
<PackageReference Include="Microsoft.AspNetCore.Mvc.TagHelpers" Version="2.1.3" />
<PackageReference Include="System.Linq.Queryable" Version="4.3.0" />

When I consume the nuget in asp.net core 3 web app it works, and I would think that since the app uses 3.0, it is overriding the older versions.

Is that true or false? Do I really need to add a FrameworkReference for netcoreapp3?

[benmccallum]

Does pulling in the whole framework (rather than just say .Http.Abstractions) have a side effect of increasing startup time? I'm not worried about the disk space increase, but is the whole fx "loaded in" when the app starts up? I'm thinking of the serverless context, where one of the recommendations is to limit static classes to drop cold starts.

[Tratcher]

@benmccallum no, the runtime still only loads assemblies on demand.

Static classes are only initialized the first time you reference them, they shouldn't affect startup time.