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

[martincostello]

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 martincostello/adventofcode@60fbfa4 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

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

Issue Details

---

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 martincostello/adventofcode@60fbfa4 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

Author:	martincostello
Assignees:	-
Labels:	area-System.Runtime, untriaged
Milestone:	-

[absid89]

same error on winforms:
after Visual Studio 17.0.6 update .net SDK updated to 6.0.2

client with 6.0.1 runtime installed, launched the app and got a crash

client without runtime, got friendly error with link to download .net 6 runtime

[EatonZ]

Related

[tannergooding]

CC. @safern, @ericstj

[ericstj]

System.Runtime, Version=6.0.0.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

The problem here is that the AssemblyVersion should not change. Can we double check if the package has this change? If it does we need to fix that -- only FileVersion can change for the reference assembly in servicing. In the meantime, you can workaround this by using the 6.0.0 version of System.Runtime.Experimental and the workaround from here #62840 (comment)

@absid89 -- looks like you might be hitting something different. Care to open a seperate issue and include a full set of repro steps?

[martincostello]

Looking at NuGet package explorer, the version in the assembly is indeed 6.0.0.1.

[ericstj]

Yes, that agrees with what you're observing. I was able to see what's happening. This is what's changing it:

runtime/eng/packaging.targets

Line 48 in ee4640a

<AssemblyVersion Condition="'$(_AssemblyInTargetingPack)' != 'true'">$(MajorVersion).$(MinorVersion).0.$(ServicingVersion)</AssemblyVersion>

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.

[safern]

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.

[ericstj]

Do you know why we use IsNetCoreAppSrc here

runtime/eng/packaging.targets

Line 46 in ee4640a

<_AssemblyInTargetingPack Condition="('$(IsNETCoreAppSrc)' == 'true' or '$(_IsAspNetCoreApp)' == 'true' or '$(_IsWindowsDesktopApp)' == 'true') and '$(TargetFrameworkIdentifier)' != '.NETFramework'">true</_AssemblyInTargetingPack>

That's only defined for a src project and not ref

Maybe we could use '$(IsNETCoreAppSrc)' == 'true' or '$(IsNETCoreAppRef)' == 'true' or create a property that corresponds to the assembly lookup (eg: IsNETCoreApp)

runtime/src/libraries/Directory.Build.targets

Lines 36 to 41 in 64f3bae

	<IsNETCoreAppSrc Condition="'$(IsNETCoreAppSrc)' == '' and
	'$(IsSourceProject)' == 'true' and
	$(NetCoreAppLibrary.Contains('$(AssemblyName);'))">true</IsNETCoreAppSrc>
	<IsNETCoreAppRef Condition="'$(IsNETCoreAppRef)' == '' and
	'$(IsReferenceAssembly)' == 'true' and
	$(NetCoreAppLibrary.Contains('$(AssemblyName);'))">true</IsNETCoreAppRef>

That would have been true for this assembly, since it's named System.Runtime

[tannergooding]

Is there something we can do to help test/validate/catch these issues before shipping?

[safern]

Do you know why we use IsNetCoreAppSrc here

I believe the wrong assumption was made? https://github.com/dotnet/runtime/pull/57158/files#r687259631

I think this is because we never had cases like the System.Runtime.Experimental scenario where we ship a ref only package and the implementation is inbox.

I think that would be a better solution than what I proposed above.

Is there something we can do to help test/validate/catch these issues before shipping?

That'd be hard as all these lists are "static" and we could've made the wrong assumption when testing (that we only need to check for IsNetCoreAppSrc.