Test fails after update 17.6.5->17.7.1 - System.IO.FileLoadException: Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

[fowl2]

A test that passed before is now failing after an update of the tools.

The error is:

   Test method redacted.Tests.redacted.redacted threw exception: 
System.IO.FileLoadException: Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
  Stack Trace:
   at System.ReadOnlyMemory`1.get_Span()
   at System.Text.Json.JsonDocument.Parse(ReadOnlyMemory`1 json, JsonDocumentOptions options)
   at System.Text.Json.JsonDocument.Parse(String json, JsonDocumentOptions options)
   at redacted() in D:\a\1\s\src\redacted.cs:line 7
   at redacted() in D:\a\1\s\src\redacted.Tests\redacted.cs:line 10

This change looks scary where it changes how System.* dlls are copied. Emphasis on the The located assembly's manifest definition does not match the assembly reference and he differing version between the error message and what is in the output folder.

packages.lock.json snippet:

      "System.Runtime.CompilerServices.Unsafe": {
        "type": "Transitive",
        "resolved": "6.0.0",
        "contentHash": "/iUeP3tq1S0XdNNoMz5C9twLSrM/TH+qElHkXWaPvuNOt+99G75NrV0OS2EqHx5wMN7popYjpc8oTjC1y16DLg=="
      },

Environment

TargetFramework: net48

Failing in Azure DevOps since the image was updated today. Verified it also fails on my local Windows dev machine after updating VS.

Versions from the pipeline:

Component	Old / Working	New / Failing	diff
VSTest@2 Azure DevOps task	2.224.0	2.227.0	microsoft/azure-pipelines-tasks@e037603
DtaExecutionHost	19.210.32906.4	19.226.34002.2
vstest.console.exe Microsoft (R) Test Execution Command Line Tool (x64)	17.6.2	17.7.0
Azure DevOps Pipeline Image	20230804.1.0	20230820.1.0	actions/runner-images@568917b
Visual Studio Enterprise 2022	17.6.33829.357	17.7.34009.444

Project File

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net48</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <ProjectReference Include="..\redacted\redacted.csproj" />
    <ProjectReference Include="..\redacted\redacted.csproj">
      <Project>{09226a53-4426-423c-a014-33b4473e4aa8}</Project>
      <Name>redacted</Name>
    </ProjectReference>
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="MSTest.TestAdapter">
      <Version>3.1.1</Version>
    </PackageReference>
    <PackageReference Include="MSTest.TestFramework">
      <Version>3.1.1</Version>
    </PackageReference>
  </ItemGroup>

</Project>

[nohwnd]

Could you show the dependencies you have in the tested project please?

Are there any other dependencies in your test project or just the test framework?

[nohwnd]

We've updated the .Unsafe library, which was "accidentally" making your project work. At least that is how I understand the problem. Please try adding Microsoft.NET.Test.SDK package reference to your project, or try adding <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType> into your project properties. This should generate the correct redirects, so the library that is trying to load the 4.x.x uses 6.x.x instead of loading the 4.x.x from test platform, and then later silently skipping loading 6.x.x.

[nohwnd]

https://developercommunity.visualstudio.com/t/Tests-fail-on-VS-1770-but-not-in-176/10441058

[fowl2]

Thanks!

Adding <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType> into the test project worked.

A bit surprising as I'd always considered test projects to be libraries only - and binding redirects I thought only operated on exes/hosts. I guess there's some magic- AppDomain/AssemblyLoadContext? - but then wouldn't it be seperated from the test platform too?

Adding a package reference to Microsoft.NET.Test.SDK to the test project didn't help btw.

so the library that is trying to load the 4.x.x uses 6.x.x instead of loading the 4.x.x from test platform,

Ahh that makes sense. The tested project brings in v6, and has the moral equivalent of GenerateBindingRedirectsOutputType jury rigged binding redirect mechanism using AppDomain.CurrentDomain.AssemblyResolve because it's an Azure Functions v1 project that doesn't support that normally.

then later silently skipping loading 6.x.x.

How is that possible?

Are there any other dependencies in your test project or just the test framework?

That's the complete project file for the test project.

Another day, another fight with dependencies and assembly binding - I'm unblocked. Thanks again.