Conflict resolution from desktop MSBuild fails to get assembly identity from cross-gen'ed linux binaries

1. Crete a new console project.
2. Modify the contents to the following.

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

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <RuntimeIdentifier>centos.7-x64</RuntimeIdentifier>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="System.Threading" Version="4.3.0" />
  </ItemGroup>

</Project>

1. dotnet restore
2. dotnet publish --> works correctly
3. msbuild /t:publish --> app will fail to start with a refdef mismatch for System.Threading.

This is because the System.Threading.dll conflict isn’t being resolved. If you examine the log you’ll see

Encountered conflict between 'CopyLocal:C:\Users\ericstj\.nuget\packages\runtime.linux-x64.microsoft.netcore.app\2.0.0\runtimes\linux-x64\lib\netcoreapp2.0\System.Threading.dll' and 'CopyLocal:C:\Users\ericstj\.nuget\packages\system.threading\4.3.0\lib\netstandard1.3\System.Threading.dll'.  Could not determine a winner because 'CopyLocal:C:\Users\ericstj\.nuget\packages\runtime.linux-x64.microsoft.netcore.app\2.0.0\runtimes\linux-x64\lib\netcoreapp2.0\System.Threading.dll' is not an assembly.

Compare this to the following in dotnet publish:

Encountered conflict between 'CopyLocal:C:\Users\ericstj\.nuget\packages\runtime.linux-x64.microsoft.netcore.app\2.0.0\runtimes\linux-x64\lib\netcoreapp2.0\System.Threading.dll' and 'CopyLocal:C:\Users\ericstj\.nuget\packages\system.threading\4.0.11\lib\netstandard1.3\System.Threading.dll'.  Choosing 'CopyLocal:C:\Users\ericstj\.nuget\packages\runtime.linux-x64.microsoft.netcore.app\2.0.0\runtimes\linux-x64\lib\netcoreapp2.0\System.Threading.dll' because AssemblyVersion '4.1.0.0' is greater than '4.0.11.0'.

It would seem that the desktop implementation for getting the assembly version can’t handle the cross-gened assemblies, however the core implementation can.

[tmat]

I think it would be interesting to look into using ILLink for task assemblies. Merge and tree-shake all dependencies of a task except for MSBuild assemblies into a single DLL. Then we would not have any versioning issues.

[nguerrera]

Spoke to @tmat offline about @jaredpar’s specific concern of just having a mismatched S.R.M or S.C.I on disk in VS install breaking VS ngen. It seems to not be an issue here because the directories probed are defined in vsn.exe.config. There are various copies of different versions in Program Files\dotnet (where we install, not in the list) and they haven’t ever triggered a VS NGEN break.

So I think we can carry v1.5.0 and use it on a fallback path (so that we don’t load / JIT unnecessarily). And without any app-domain or assembly resolve shenanigans.

I think there’s non-negligible risk here, but I’m not seeing how to fix this bug without taking it.

I do like the idea of static linking things like nuget and srm into the build task at some point, but I don’t think we can afford to make that a pre-req of this bug fix.