Discussion for Introduction of new meta-package "Microsoft.AspNetCore.App"

[DamianEdwards]

Discussion issue for aspnet/Announcements#287

[yang-xiaodong]

I think packaging Microsoft.AspNetCore.All into the SDK is a very bad decision and one day you guys will remove them from the SDK.

[jchannon]

Microsoft.AspNetCore.All is an optional package currently. Are you saying that Microsoft.AspNetCore.App is a requirement for 2.1 apps?

[davidfowl]

You can always reference individual packages.

[scottaddie]

@davidfowl I'm assuming this new metapackage isn't to be used by apps targeting .NET Framework instead of .NET Core. Is that correct?

[Eilon]

@scottaddie yes it's .NET Core only.

[DamianEdwards]

@scottaddie @Eilon actually we're working with the .NET team to get the linker (trimmer) working on ASP.NET Core applications targeting .NET Framework, so that we can allow the meta-package to work on .NET Framework targeted apps too. This is currently in scope for 2.1, although will not make it for the first preview. We'll keep folks posted.

[mungojam]

Is there an explanation for the reasoning behind this change? I feel there is some interesting background missing

[DamianEdwards]

@mungojam sorry for the delay, yes indeed there is some more context I've been meaning to add. There's two main things:

• The new meta-package doesn't contain packages that we aren't able to support and/or service (as in, forcibly release patches for e.g. in cases of critical security issues). The three that are included we were unable to remove while keeping the core products functional, but we also don't anticipate any support or servicability issues with them. In the future (like, 3.0 and beyond) we'll be taking a modified approach to how we integrate with and ship 3rd party libraries to ensure a clear story for our "default" product experience, i.e. using Microsoft.AspNetCore.App results in your app using MS-supported and servicable bits.
• The other part is the new meta-package includes version restrictions, such that other packages you might bring in, can't unintentionally upgrade bits of what's in Microsoft.AspNetCore.App higher than the version included. This helps to ensure a more reliable experience, as it becomes harder to end up with untested version combinations of related bits being used together in the same app (a large cause of customer issues today, given it often happens completely silently). You'll still be able to force it in the cases you want to do so (by lifting the affected package references to be direct in your project) but at that point you're effectively in an unsupported state.

[mungojam]

@DamianEdwards thanks, those make sense.

On the second point, that's an interesting one. What if people are adding later versions for direct use in their projects but don't realise that the meta package also has a dependency on them? Hoping it would lead to a build warning.

[DamianEdwards]

@mungojam indeed NuGet will give you a warning if you force an override of a version range restriction by hoisting the dependency. You can optionally suppress the warning I believe, but by default you'll be notified you're going outside the lines.

[MV10]

The other part is the new meta-package includes version restrictions, such that other packages you might bring in, can't unintentionally upgrade bits of what's in Microsoft.AspNetCore.App higher than the version included.

Isn't this going to lead to the same hassles the Azure Functions team is struggling with due to binding redirects? Using any recent version of something as crucial as JSON.NET with Functions v1 is currently very troublesome due to a hard dependency on an old version:

Azure/azure-functions-host#992