aspnetcore: Version mismatches in 2.1 and 2.2 patch updates (often causes FileLoadException)

Some ASP.NET Core 2.1 users have been affected by a bug in the .NET Core host (see https://github.com/dotnet/core-setup/issues/4512) which can cause apps to fail with System.IO.FileLoadException. The issue may also be present in your app, even if the app does not fail with System.IO.FileLoadException.

Affected versions

.NET Core, 2.1.1 through 2.1.4 (all OSes), 2.1.7 (Windows only), 2.2.1 (Windows only)

Symptom 1

ASP.NET Core apps running on the Microsoft.AspNetCore.App shared framework may fail to run after the machine-wide version of .NET Core is updated. Apps fail with an error such as:

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly ‘Microsoft.Extensions.Identity.Core, Version=2.1.3.0, Culture=neutral, PublicKeyToken=adb9793829ddae60’. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) at Diary.Api.Startup.ConfigureServices(IServiceCollection services)

Symptom 2

When publishing an ASP.NET Core application which references Microsoft.AspNetCore.App, additional Microsoft assemblies are in the publish output.

For example, if you run dotnet publish --output PublishDir/ and you see Microsoft.Extensions.*.dll or Microsoft.AspNetCore.*.dll files in PublishDir/, you may be running into this issue.

Cause

This issue is typically caused by .csproj files which have a PackageReference to a package which is already part of Microsoft.AspNetCore.App.

For example,

<ItemGroup>
  <PackageReference Include="Microsoft.AspNetCore.App" />
  <PackageReference Include="Microsoft.AspNetCore.SignalR" Version="1.0.3" />
</ItemGroup>

The Microsoft.AspNetCore.SignalR package is already pulled in as a part of Microsoft.AspNetCore.App, so does not normally need to be referenced. The presence of this reference causes a mismatch of versions, which in turn causes a problem with the .NET Core host, as described in https://github.com/dotnet/core-setup/issues/4376.

More technical details here: https://github.com/Azure/app-service-announcements-discussions/issues/65#issuecomment-417379227

Workaround 1

Remove PackageReference’s which are already part of Microsoft.AspNetCore.App. You can find a list of what this package pulls in by looking at https://www.nuget.org/packages/microsoft.aspnetcore.app#show-dependency-groups. This will avoid the version mismatch.

Workaround 2

Upgrade the Microsoft.AspNetCore.App PackageReference to the latest 2.1.x version by adding the Version attribute.

  <PackageReference Include="Microsoft.AspNetCore.App" Version="2.1.3" />

⚠️ This may have unintended consequences on your deployment environment. If the deployment environment does not have the the 2.1.3 runtime, apps will fail to start with an error. In Azure or apps hosted behind IIS, this may appear as HTTP 502.5 error.

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 9
Comments: 17 (9 by maintainers)

Commits related to this issue

Fix #3503 - update buildtools dependency on DependencyModel to 2.1.0 The 2.0 version of the Microsoft.Extensions.DependencyModel does not support the assembly/file version metadata. We must have at l... — committed to natemcmaster/AspNetCore by deleted user 5 years ago
Fix #3503 - update buildtools dependency on DependencyModel to 2.1.0 The 2.0 version of the Microsoft.Extensions.DependencyModel does not support the assembly/file version metadata. We must have at l... — committed to dotnet/aspnetcore by deleted user 5 years ago

Most upvoted comments

Proposed fix => https://github.com/aspnet/AspNetCore/pull/6619. It needs to go through approval channels first, but assuming that happens, this will be fixed in 2.1.8 and 2.2.2.

natemcmaster on Jan 11, 2019

@axelheer Installing the update on our servers would make them all crash

I’ve opened https://github.com/aspnet/AspNetCore/issues/7546 to resolve the 2.1.7 -> 2.1.8 issue which causes FileLoadException.

You are correct that Workaround 1 does not work if you depend on other things which pull in AspNetCore transitively packages. We’re addressing this in 3.0 with a fundamental redesign of the way we version and distribute aspnetcore packages and assemblies. In the meantime, use Workaround 2.

@jeremyVignelles: When removing the explicit version, the app works, but I’m afraid of the impact of unwanted updates. If we remove the version, will it always stay in the 2.1.x branch?

By default, .NET Core will run on the highest patch version of 2.1.* installed on the machine, regardless of the presence/absence of the Version attribute on the PackageReference to AspNetCore.App. Version should really have been named MinimumVersion. This is a common pitfall, so you’re not the first to ask.

When you remove the explicit version attribute and build a self-contained application (dotnet publish -r win-x64), the .NET Core SDK will attempt to give you the latest version of AspNetCore.App. To get a newer version of aspnetcore in a self-contained app, you should either (1 - recommended) update the SDK or (2 - as a workaround) set the <RuntimeFrameworkVersion> property to the version you want to use.

If you want to further control the way in which your application rollsforward (or does not rollforward) to new versions, checkout instructions here: https://natemcmaster.com/blog/2019/01/09/netcore-primitives-3/#automatically-run-on-higher-patch-versions

natemcmaster on Feb 13, 2019