Local test run fails for target net461 with FileLoadException S.R.CS.Unsafe

[devsko]

Description

Running tests locally for target framework net461 fail when using dotnet build /t:test as well as in VS Test Explorer for projects that reference System.Memory and System.Runtime.CompilerServices.Unsafe like System.Collections.Immutable or System.Text.Json and others. I believe it started to fail with #41616

Example for dotnet build /t:test System.Collections.Immutable.Tests

        System.IO.FileLoadException : Die Datei oder Assembly "System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" oder eine Abhängigkeit davon wurde nicht gefunden. Fehler bei der Überprüfung des starken Namens. (Ausnahme von HRESULT: 0x8013141A)
        ---- System.Security.SecurityException : Fehler bei der Überprüfung des starken Namens. (Ausnahme von HRESULT: 0x8013141A)
        Stack Trace:
             bei System.ReadOnlySpan`1..ctor(T[] array, Int32 start, Int32 length)
             bei System.ReadOnlyMemory`1.get_Span()
             bei System.ReadOnlyMemory`1.ToArray()
             bei System.Collections.Immutable.Tests.ImmutableArrayTest.AsMemoryRoundTripStringTests(IEnumerable`1 source) 

My usual workflow before running tests

git checkout master
git clean -xdf --exclude=**/.vs 
git pull origin master
build.cmd clr+libs -rc Release
build.cmd libs -f net48

Configuration

Current master branch
VS 16.8 preview 3

Regression?

Yes, it worked until about a week ago

Tagging subscribers to this area: @safern, @ViktorHofer
See info in area-owners.md if you want to be subscribed.

[ericstj]

@ViktorHofer it appears like we aren't seeing a bindingRedirect for System.Runtime.CompilerServices.Unsafe on .NETFramework. Likely this is because the Unsafe reference isn't appearing in the reference assembly of System.Memory. Not sure why test runs aren't seeing this.

[ericstj]

I couldn't repro this. For me I see that System.Collections.Immutable.Tests get's a System.Collections.Immutable.Tests.dll.config with a bindingRedirect for System.Runtime.CompilerServices.Unsafe.

If I examine C:\src\dotnet\runtime\artifacts\bin\System.Collections.Immutable.Tests\net461-Debug\System.Collections.Immutable.Tests.dll.config I see

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <runtime>
    <UseRandomizedStringHashAlgorithm enabled="1" />
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

And the tests run successfully.

Also, not sure if you knew, but to do this thing you suggested here you actually don't need any up front builds. You can simply clone the repo and run dotnet test on the test project.

This works from a clean clone, thanks to @ViktorHofer's work.

git clean -xdf --exclude=**/.vs 
dotnet test src\libraries\System.Collections.Immutable\tests\System.Collections.Immutable.Tests.csproj -f:net461

If you're still able to reproduce this please share a binlog for the failing command by passing /bl to the failing command and sharing the msbuild.binlog it produces.

[devsko]

@ericstj Thanks for the help.
I found the solution:

sn -Vr *,B03F5F7F11D50A3A (Maybe this should be mentioned in the docs :)

---

You can simply clone the repo and run dotnet test on the test project.

It works in this case. But - not sure if you know - it fails in many other cases

git clean -xdf
dotnet test src\libraries\System.Text.Json\tests\System.Text.Json.Tests.csproj

This fails to compile System.IO.Pipelines and even after build libs the test host fails with Could not resolve CoreCLR path.
But I'm totally fine with a complete build every now and then.

[ViktorHofer]

That is expected as NetFramework is a pre-built (it exists on your machine) vs NETCore which is a live built (it's part of the repository). We were discussing options to initialize the repository with a known last good build so that you don't need to rebuild the full repo, i.e. when you just want to build and test the libraries. But that problem hasn't been solved yet.