Application fails to start using System.Runtime.Experimental 6.0.1 with .NET 6.0.2 #65018
Comments
dotnet-issue-labeler
bot
added
the
untriaged
|
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 Issue DetailsDescriptionAttempting 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. This appears to be related to the fix for #62840 in #63525. This can be worked around by using version Reproduction StepsClone martincostello/adventofcode@60fbfa4 and then run the following commands: .\build.ps1 -SkipTests -Runtime win10-x64
cd .\artifacts\publish
.\AdventOfCode.Site.exeExpected behaviorThe 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 behaviorThe 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 WorkaroundsUse the 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 informationNo response
|
|
same error on winforms: 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 |
The problem here is that the @absid89 -- looks like you might be hitting something different. Care to open a seperate issue and include a full set of repro steps? |
|
Looking at NuGet package explorer, the version in the assembly is indeed 6.0.0.1.
|
|
Yes, that agrees with what you're observing. I was able to see what's happening. This is what's changing it: Line 48 in ee4640a We aren't hitting this for the non-experimental System.Runtime (or other refpack assemblies) because we never set |
|
I think we can add a condition to disable automatically bumping the |
|
Do you know why we use Line 46 in ee4640a That's only defined for a src project and not ref
Maybe we could use runtime/src/libraries/Directory.Build.targets Lines 36 to 41 in 64f3bae That would have been true for this assembly, since it's named |
|
Is there something we can do to help test/validate/catch these issues before shipping? |
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.
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 |
|
Related #63467
API Compat could have caught it. That would have caught this since inbox S.R wouldn't have satisfied the ref. Perhaps APICompat is not honoring assembly version? I know we made changes in the new API compat to do that. https://github.com/dotnet/sdk/blob/aecf5b5cc13e93dd8c377c502490bcf714565a5a/src/Compatibility/Microsoft.DotNet.ApiCompatibility/Rules/AssemblyIdentityMustMatch.cs#L57-L59 Another thing we often ask folks to do is verify the end-to-end scenario in the final builds. We usually ask folks contributing servicing changes to adhoc validate the end-to-end scenario in final bits to ensure that its fixed. We should definitely have @tannergooding help with this when we fix it again. Since the current package |
sorry i had to write in the winforms thread |
Revert to the 6.0.0 release of System.Runtime.Experimental and re-apply the workaround until dotnet/runtime#65018 is resolved.
tannergooding
removed
the
untriaged
|
Fixed in #65166. |
|
We still need to make sure the new package is created for 6.0.4 release, so we need to add |
ghost
added
the
in-pr
ghost
removed
the
in-pr
|
|
ghost
locked as resolved and limited conversation to collaborators
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.
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.8of the package so that the version numbers align.Reproduction Steps
Clone martincostello/adventofcode@60fbfa4 and then run the following commands:
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.
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.8version of theSystem.Runtime.Experimentalpackage.Configuration
Other information
No response
The text was updated successfully, but these errors were encountered: