runtime: Application fails to start using System.Runtime.Experimental 6.0.1 with .NET 6.0.2

Description

Attempting to run a self-contained deployment of a ASP.NET Core application using the .NET 6.0.102 SDK with System.Runtime.Experimental 6.0.1 fails with the following error when run.

Unhandled exception. System.IO.FileLoadException: Could not load file or assembly 'System.Runtime, Version=6.0.0.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The located assembly's manifest definition does not match the assembly reference. (0x80131040)
File name: 'System.Runtime, Version=6.0.0.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

This appears to be related to the fix for #62840 in #63525.

This can be worked around by using version 6.0.2-mauipre.1.22054.8 of the package so that the version numbers align.

Reproduction Steps

Clone https://github.com/martincostello/adventofcode/commit/60fbfa4076b430b0da70d8c8021a8502bb2585d7 and then run the following commands:

.\build.ps1 -SkipTests -Runtime win10-x64
cd .\artifacts\publish
.\AdventOfCode.Site.exe

Expected behavior

The ASP.NET Core application starts using the NuGet package that shipped today as part of the .NET 6.0.2 release, rather than requiring the use of a prerelease package for MAUI.

Actual behavior

The ASP.NET Core application fails to start.

> .\AdventOfCode.Site.exe
Unhandled exception. System.IO.FileLoadException: Could not load file or assembly 'System.Runtime, Version=6.0.0.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The located assembly's manifest definition does not match the assembly reference. (0x80131040)
File name: 'System.Runtime, Version=6.0.0.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

Regression?

Compared to .NET 6.0.0, yes.

.NET 6.0.1 was broken without a workaround being applied.

Known Workarounds

Use the 6.0.2-mauipre.1.22054.8 version of the System.Runtime.Experimental package.

Configuration

> dotnet --info
.NET SDK (reflecting any global.json):
 Version:   6.0.102
 Commit:    02d5242ed7

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.22000
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.102\

Other information

No response

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 17 (14 by maintainers)

Commits related to this issue

Revert System.Runtime.Experimental Revert to the 6.0.0 release of System.Runtime.Experimental and re-apply the workaround until dotnet/runtime#65018 is resolved. — committed to martincostello/adventofcode by martincostello 2 years ago

Most upvoted comments

We still need to make sure the new package is created for 6.0.4 release, so we need to add ServicingVersion=2 and GeneratePackageOnBuild=true to the System.Runtime.Experimental.csproj in the release/6.0 branch, so we should keep this open until that PR is created and merged.

safern on Feb 15, 2022

I think we can add a condition to disable automatically bumping the AssemblyVersion when a package is not in the targeting pack and set that flag to true on System.Runtime.Experimental.

safern on Feb 9, 2022

Yes, that agrees with what you’re observing. I was able to see what’s happening. This is what’s changing it: https://github.com/dotnet/runtime/blob/ee4640a6a34e4410c7925615569019edf0ff4289/eng/packaging.targets#L48

We aren’t hitting this for the non-experimental System.Runtime (or other refpack assemblies) because we never set ServicingVersion for them, but we did set it for this reference project.

ericstj on Feb 9, 2022