Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=6.0.1.0 on Framework leg

[Forgind]

Build Information

Build: https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_build/results?buildId=999341
Build error leg or test failing: dotnet.Tests.dll.10.WorkItemExecution
Pull request: #48022

Error Message

Fill the error message using step by step known issues guidance.

{
  "ErrorMessage": "System.TypeInitializationException: The type initializer for 'System.Text.Encodings.Web.DefaultJavaScriptEncoder' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=6.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.",
  "ErrorPattern": "",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Known issue validation

Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=999341
Error message validated: [System.TypeInitializationException: The type initializer for 'System.Text.Encodings.Web.DefaultJavaScriptEncoder' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=6.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 3/31/2025 6:10:46 PM UTC

Report

Build	Definition	Test	Pull Request
1006059	dotnet/sdk	Microsoft.NET.Sdk.Razor.Tests.dll.7.WorkItemExecution	#48034
1005479	dotnet/sdk	Microsoft.NET.Sdk.Razor.Tests.dll.7.WorkItemExecution	#48034
1005022	dotnet/sdk	Microsoft.NET.Build.Tests.dll.13.WorkItemExecution	#48034
1003621	dotnet/sdk	Microsoft.NET.Sdk.Razor.Tests.dll.7.WorkItemExecution	#48034
1002015	dotnet/sdk	Microsoft.DotNet.Cli.Test.Tests.GivenDotnetTestBuildsAndRunsTestfromCsprojWithCorrectTestRunParameters.Microsoft.DotNet.Cli.Test.Tests.GivenDotnetTestBuildsAndRunsTestfromCsprojWithCorrectTestRunParameters.GivenADllAndMultipleTestRunParametersItPassesThemToVStestConsoleInTheCorrectFormat	#48034
1001453	dotnet/sdk	Microsoft.DotNet.Cli.Test.Tests.GivenDotnetTestBuildsAndRunsTestfromCsprojWithCorrectTestRunParameters.Microsoft.DotNet.Cli.Test.Tests.GivenDotnetTestBuildsAndRunsTestfromCsprojWithCorrectTestRunParameters.GivenADllAndMultipleTestRunParametersItPassesThemToVStestConsoleInTheCorrectFormat	#48034
1000499	dotnet/sdk	Microsoft.NET.Sdk.BlazorWebAssembly.Tests.dll.1.WorkItemExecution	#48034
999715	dotnet/sdk	Microsoft.DotNet.Cli.Test.Tests.GivenDotnetTestBuildsAndRunsTestfromCsprojWithCorrectTestRunParameters.Microsoft.DotNet.Cli.Test.Tests.GivenDotnetTestBuildsAndRunsTestfromCsprojWithCorrectTestRunParameters.GivenADllAndMultipleTestRunParametersItPassesThemToVStestConsoleInTheCorrectFormat	#48034
999341	dotnet/sdk	Microsoft.NET.ToolPack.Tests.dll.1.WorkItemExecution	#48022

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
0	9	9

[Forgind]

@dotnet/dotnet-runtime-triage
As far as I can tell, we're calling the same method of the same assembly, but something is causing us to look for a later version than before. I'm not really sure where to go from here. Can someone please take a look?

[baronfel]

@Forgind based on chatter in this PR I think it was a dotnet/runtime codeflow that introduced a bug that wasn't meant to merge: #47898

[teo-tsirpanis]

(also, the dotnet-runtime-triage team contains community members with triage permissions on the dotnet/runtime repository, not people to respond to CI failures related to dotnet/runtime 😅)

[Forgind]

(also, the dotnet-runtime-triage team contains community members with triage permissions on the dotnet/runtime repository, not people to respond to CI failures related to dotnet/runtime 😅)

Ah, sorry. It sounded good when I tried looked for names like dotnet-runtime. I'll try to avoid doing that again.

[akoeplinger]

The runtime codeflow PR was reverted in #48020

[am11]

Similar change (S.R.CompilerServices.Unsafe 6.0.0.0->6.0.1.0) in msbuild was reverted today dotnet/msbuild#11038. Perhaps these toolchain package versions should be defined at a central location because they have hard dependency on VS schedules (and not independent like other packages).

If arcade is not right place dotnet/arcade#10516 (comment), maybe we should centrally define them in dotnet/sdk because syncing them manually across half dozen repos is a pain point.

[Forgind]

Similar change (S.R.CompilerServices.Unsafe 6.0.0.0->6.0.1.0) in msbuild was reverted today dotnet/msbuild#11038. Perhaps these toolchain package versions should be defined at a central location because they have hard dependency on VS schedules (and not independent like other packages).

If arcade is not right place dotnet/arcade#10516 (comment), maybe we should centrally define them in dotnet/sdk because syncing them manually across half dozen repos is a pain point.

I put a not-dissimilar suggestion here. Sounded like the long-term plan is to use the VMR as that central place to define versions.

[ericstj]

This should not be a permitted build error. We were discussing in #48034 - fix is in progress.

Were you hitting this in builds that didn't have the runtime update or System.Memory update? @carlossanlop

[Forgind]

What do you mean by 'permitted build error'?

[akoeplinger]

It shouldn't be a "Known issue" that would make people ignore it in Build Analysis.
According to the analysis it only happened in #48034, closing the issue so we don't accidentally ignore it.

[Forgind]

According to the analysis it only happened in #48034, closing the issue so we don't accidentally ignore it.

This happened in a lot more than one PR. I might have made the exact description too narrow, but I saw this pop up in at least 5-10 code flow PRs all at once. I filed an issue for it to indicate that we should fix it, not so we could ignore it. To me, at least, an issue like this means someone needs to be responsible for fixing it, but the rest of the world can move on while that happens, which perfectly describes this situation. Someone does need to fix it, but other PRs shouldn't be blocked.