Stop producing packages for shared framework assemblies in 3.0 #3756
Comments
natemcmaster
added
the
feature-platform
|
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? |
Yes. The SDK and NuGet teams are still working on the details of how
Correct. We are removing the |
|
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? |
|
@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. |
|
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 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. |
|
@owainc so you’re main concern is about deployment size? Today you’re using packages to minimize the dependencies? Is there something else? |
|
@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. |
|
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. 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) ? |
|
@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? |
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.
Self-contained deployment will continue to be supported. This issue tracks some packaging work we have to do to keep this working: #3607
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
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. |
|
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 ***@***.***> 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
<#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 <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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#3756 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAGapnZWeUTL2cUUZ7XlIol-zucs3KxWks5uqILQgaJpZM4YAssQ>
.
|
|
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. |
There are 1000 aspects of aspnetcore and System.Web we could compare. Did you have any particular that you're concerned about?
😄 happy to help. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
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. |
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.
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.
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. |
|
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. |
|
@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. |
|
@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:
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 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 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 :)). |
|
For 3.0.0 preview1, we have removed most packages from shipping, except as noted below. |
|
@natemcmaster @davidfowl Is Microsoft.Extensions.DependencyInjection library still going to be in a different package that ASP.NET Core 3.0? In Extensions. |
|
Yes, most Microsoft.Extensions.* libraries will continue to ship as a normal nuget packages.
|
|
I have a pagination library that is currently netstandard2.0 https://github.com/cloudscribe/cloudscribe.Web.Pagination 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? |
|
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. |
|
@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. |
JunTaoLuo
added
area-infrastructure
💡 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 #3608, #3610, and #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 )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:
The text was updated successfully, but these errors were encountered: