With the release of .NET Core 2.0 comes a large “meta package” with the name Microsoft.AspNetCore.All. It’s a sort of god mode package that contains all you need to get up and running on ASP.net Core without having to figure out which nuget package does what. But it does have some massive pitfalls in my opinion.
Why Have A Meta Package At All?
When ASP.net Core is split into multiple smaller packages, the “versions” of these packages start to get all out of sync over time. This is especially true if you have ever tried to upgrade a project between .NET core versions, you end up having to go through all your smaller AspNetCore packages and work out which ones you should be version bumping. Take the following for example :
<PackageReference Include="Microsoft.AspNetCore" Version="1.0.4" /> <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.0.3" /> <PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="1.0.2" /> <PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="1.0.3" /> <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="1.0.3" /> <PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer.Design" Version="1.0.3" />
Here you have many aspnetcore and EntityFramework packages that all have slightly off versions. In ASP.net Core 2.0, using the “Microsoft.AspNetCore.All” meta package, your package references instead look like this :
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" />
What this should mean is that by updating a single package, you will be able to run on the latest ASP.net Core version. It also makes your csproj a bit easier on the eye with a single package being your “framework”, and any other package references being ones you have added explicitly.
What’s Inside The Microsoft.AspNetCore.All package
The meta package contains :
- Every single AspNetCore package published by Microsoft
- Every EntityFrameworkCore package published by Microsoft
- Any supporting packages required for the framework to run (For example Json.Net)
Now, that probably sounds huge and you will probably ask yourself, won’t the resulting deployment be out of control? You would essentially be “shipping” the entire framework right? Well..
Deployment and Runtime Store
Microsoft have gone back to something called the “Runtime Store“. I say the words “gone back” because this functions almost the same as the GAC on .net Full Framework projects. That is, your target machine would have to have the .NET Core runtime installed on it for you to be able to use the aspnetcore meta package. When you deploy, you won’t actually deploy any of the framework packages, your code will instead utilize the ones already on the machine.
And if the machine doesn’t have the runtime installed? Well, that’s where things start to fall down. If you are looking to do self contained deployments (Which was a massive selling point of .NET Core), then you cannot use the meta package. You would need to reference packages manually. I can see how this could turn into a headache down the road because it makes the creation of the project and whether you use the meta package so important. Imagine getting to the point you are ready to deploy, and your dev ops team prefers going down a self contained deployment route. Now you will have to go back and work out which packages you are using from the meta and add them all in manually. Painful!
Getting Started
By default, when you create any project using ASP.net Core 2.0, you will be using the meta package. If you know you won’t be using self contained deployments any time soon, then it’s safe to go ahead and use, and really, it does alleviate some headaches of knowing which packages have what. I can’t tell you how many times I start a new project and I have to go back and manually add in the packages for authentication, entityframework, staticfiles etc. Give it a go and let me know what you think below!
