Constructor_String_LoadVersionTest failing on Fedora runs

[weshaggard]

Assert.Throws() Failure
Expected: typeof(System.IO.FileNotFoundException)
Actual:   (No exception was thrown)
Stack Trace :
   at System.Reflection.Tests.AssemblyNameTests.Constructor_String_LoadVersionTest() in /mnt/j/workspace/dotnet_corefx/master/linux-TGroup_netcoreapp+CGroup_Release+AGroup_x64+TestOuter_false_prtest/src/System.Reflection/tests/AssemblyNameTests.cs:line 559

A couple examples:
https://mc.dot.net/#/user/weshaggard/pr~2Fjenkins~2Fdotnet~2Fcorefx~2Fmaster~2F/test~2Ffunctional~2Fcli~2F/84cf25a2c8d2bd2819584e57de87a5c1c0fa6efa/workItem/System.Reflection.Tests/analysis/xunit/System.Reflection.Tests.AssemblyNameTests~2FConstructor_String_LoadVersionTest
https://mc.dot.net/#/user/stephentoub/pr~2Fjenkins~2Fdotnet~2Fcorefx~2Fmaster~2F/test~2Ffunctional~2Fcli~2F/b4be508ae9f11a42286a828728d537eca987d0bb/workItem/System.Reflection.Tests/analysis/xunit/System.Reflection.Tests.AssemblyNameTests~2FConstructor_String_LoadVersionTest

[steveharter]

Also occurred on

Windows.10.Amd64.Core-x64 
Release
RedHat.73.Amd64-x64 
Release

[steveharter]

Note the failing test is marked with [ActiveIssue]

[steveharter]

This test is not working on Windows either, it is throwing FileLoadException not FileNotFoundException.

This test is not valid for coreclr. It assumes the binding semantics of assemblyname that only exist in NetFx, not CoreFx.

The CoreFx binding\loader (core-setup) has the rough algorithm:

• During bootstrapping of the native dotnet executable, it obtains version information from the .deps.json file, not the assemblyname from the assembly manifest. This is used to support roll-forward only (major\minor\patch depending on settings).
• Passes the list of assemblies (names, not including version) to the CoreClr when initializing the CoreClr.
• When assembly is loaded, the CLR verifies the reference's assembly name is compatible with the target assembly's version (from the assembly manifest). The versions match exactly except for patch\build version.

At a minimum this test should catch FileLoadException not FileNotFoundException (at least to match current Core semantics). The file exists, just the assembly manifest version is not compatible.

[steveharter]

In CI, sometimes FileLoadException is thrown, but mostly FileNotFoundException is thrown.

In a local build (Windows x64), FileLoadException is always thrown. It is thrown because:

• IsCompatibleAssemblyVersion fails due to the AssemblyName version not equal to the manifest version.
• hr = FUSION_E_REF_DEF_MISMATCH is returned and a EEFileLoadException::Throw is performed.
• There is a subsequent check in a catch (PostBindResolveAssembly) but that just re-throws the same exception.

In a local console app, FileNotFoundException is always thrown for the same scenario.

I believe XUnit is interfering in some manner, and that the run-time semantics are consistent.

More debugging is necessary.

[steveharter]

Moving to Future; bug (likely test) also occurred in 3.1.