Pros and Cons of Microsoft.AspNetCore.All metapackage

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 necessary packages. We can include this metapackage in the .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? (In addition, consider cross-platform standalone applications as well)

Answer 1

When you create an ASP.NET Core 2.0 application that works with .NET Core 2.0, you should use Microsoft.AspNetCore.All ( Microsoft.AspNetCore.App recommended for ASP.NET Core 2.1 and higher), as this is the recommended approach and it is useful to avoid long list of dependencies.

When publishing, a tree-like transformation is applied, which means: the build process will determine which packages inside the metapackage will be used and push them out of the published folder so that the size is small.

Another reason to use it is the Runtime.NET repository . The Microsoft.AspNetCore.All package is part of the run-time repository, so it does not need to be published (as mentioned above), but more importantly, it is precompiled, so the startup time also improves.

anyway

1. You cannot use Microsoft.AspNetCore.All (or Microsoft.AspNetCore.App ) when setting up the .NET Framework> = 4.6.1, as this requires netcoreapp2.0 and netcoreapp2.1 respectively
2. You cannot and should not use it in portable class libraries (PCL) because it requires netcoreapp2.0 and PCL to target netstandard2.0 . There are a few exceptions, for example, if you depend on a package (ASP.NET Core) that works only on .NET Core (or you only need APIs on .NET Core), since netcoreappx.y targeting netcoreappx.y cannot netcoreappx.y Framework