Installing the ASP.NET Core 2.0 runtime store on Linux
This is a quick post to show how to manually install the ASP.NET runtime store on a production Linux server. Failure to do this will result in your ASP.NET Core 2.0 applications breaking.
I am in the process of migrating some .NET Core 1.1 applications to .NET Core 2.0 following its release a couple of weeks ago. My first migration was a very simple test API app. I followed the migration guide in the docs and my initial impressions were very positive.
In less than an hour I had made the necessary changes and fixed a few other issues that cropped up and had a successful compile. Running the application for the first time on my development machine, I was delighted to find that it worked perfectly. Unfortunately once I deployed to my Linux VPS (and after updating the installed runtime to 2.0), it immediately became apparent that all was not well:
An assembly specified in the application dependencies manifest (foo.deps.json) was not found: package: 'Microsoft.ApplicationInsights.AspNetCore', version: '2.1.1' path: 'lib/netstandard1.6/Microsoft.ApplicationInsights.AspNetCore.dll' This assembly was expected to be in the local runtime store as the application was published using the following target manifest files: aspnetcore-store-2.0.0-linux-x64.xml;aspnetcore-store-2.0.0-osx-x64.xml;aspnetcore-store-2.0.0-win7-x64.xml;aspnetcore-store-2.0.0-win7-x86.xml
As an aside, I am less than thrilled that Application Insights is getting loaded given that there is no reference to it in my application. I assume that this is due to the magical IHostingStartup feature. I would be interested to know if there is a way to avoid this (other than by not using the meta package).
In ASP.NET Core 2.0, the recommended approach is to replace individual ASP.NET related NuGet references with a single reference to the new ASP.NET meta package:
<ItemGroup> <PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" /> </ItemGroup>
This pulls in a huge number of other NuGet packages but the publish process apparently works out which ones you are actually using and trims the packages as necessary. Besides, none of these packages are deployed with your app...
If you have read the documentation on ASP.NET Core 2.0, then you will know that using the Microsoft.AspNetCore.All meta package opts you in to the new runtime store feature. This is basically an optimized set of libraries which are available on the server so your deployment package does not need to include them. In other words, all NuGet packages referenced by the Microsoft.AspNetCore.All metpackage will not get deployed with your app as it is assumed that those packages will already be present on the target system (in the runtime store).
From the error message, it seemed as though the runtime store was not present and looking at the folder structure, this was confirmed. Reading through some github issues, I discovered that the cache is not distributed with the .NET Core runtime. I suppose that this makes sense. The .NET Core runtime probably should not have ASP.NET specific functionality bundled with it.
The SDK does include the store but it is not best practice to install the SDK on production machines so I was looking for an alternative when Nate McMaster kindly pointed me to a tarball containing the runtime store files. At the time of writing, this is not documented so it was a very useful piece of information.
The linux ASP.NET Core 2.0 runtime store tarball is located at:
If you download and extract the file into the dotnet install folder on your VM (so you have the store folder immediately under the dotnet folder) then the errors will disappear and you ASP.NET apps will work once more.
I hope that the tooling and documentation around this process improves but for now, I hope that this post will help some other teams with ASP.NET Core 2.0 deployment issues.
Useful or Interesting?
If you liked the article, I would really appreciate it if you could share it with your Twitter followers.Share on Twitter
Be the first person to comment on this article.