Pros and cons of Microsoft.AspNetCore.All metapackage [closed]

Question

In ASP.NET Core 2.0 there is no need to include individual package references in the .csproj file. Microsoft.AspNetCore.All metapackage contains all the required packages. We can include this metapackage in .csproj file as:

<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" />

What are the main pros and cons of this metapackage in .Net Core applications? (Consider cross platform self contained applications also)

Answer 1

When you create ASP.NET Core 2.0 application running against .NET Core 2.0, you should use Microsoft.AspNetCore.All (for ASP.NET Core 2.1 and higher, Microsoft.AspNetCore.App is recommended - From ASP.NET Core 3.0 Microsoft.AspNetCore.All will be removed) as this is the recommended approach and is useful to avoid a long list of dependencies.

When publishing (self-containing) applications, tree-shaking will be applied, this means: the build process will find out which packages inside the metapackage will be used and will strip them from the published folder to keep the size small.

Another reason to use it is the .NET Core Runtime Store. The Microsoft.AspNetCore.All package is part of the runtime store so it won't need to be published (as mentioned above) but more importantly, it is precompiled, so startup times improves too.

However

1. You can't use Microsoft.AspNetCore.All (or Microsoft.AspNetCore.App) when targeting .NET Framework >= 4.6.1, because it requires netcoreapp2.0 and netcoreapp2.1 respectively
2. You can't and shouldn't use it in Portable Class Libraries (PCL) due to the fact that it requires netcoreapp2.0 and PCLs should be targeting netstandard2.0. There are a few exceptions, for example if you depend on a (ASP.NET Core) package which only runs on .NET Core (or you require .NET Core only APIs), since PCLs targeting netcoreappx.y can't run on .NET Framework