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?

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

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 <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.

@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.
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) ?

@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?

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

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.

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?

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.