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

[ericstj]

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>

3. dotnet restore
4. dotnet publish --> works correctly
5. 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.

[ericstj]

/cc @dsplaisted

Opened as a result of https://github.com/dotnet/corefx/issues/23283

[rainersigwald]

Related: dotnet/msbuild#2253 (though this should be possible by unifying to (slower) System.Reflection.Metadata where that one isn't AFAIK.

[nguerrera]

I'm seeing related strangeness from sn.exe saying crossgened binaries do not have a strong name.

What's the proposed fix on this: move everything to S.R.M? Are we just holding the COM API wrong?

[nguerrera]

@ericstj In mail, you said this was lower priority, but seems severe. What's the mitigation?

[nguerrera]

S.R.M should be just as fast if we can use an ngen'ed version as roslyn does.

[ericstj]

Mitigation is to use dotnet.exe to publish. I'm looking at another mitigation: use the S.R.M based task from VS/MSBuild.

I had initially thought this was lower pri because folks weren't doing as much cross-targeting (building on Windows to publish to unix) from VS, but I may be wrong. Just saw another case where someone hit this.

EDIT: update, I cannot use the existing S.R.M based task easily. MSBuild will only load one copy of the assembly into the process (since they have the same name) and first in wins. I can't switch everything because we're missing some of the facades that would be required by desktop to load the netcoreapp assembly.

[ericstj]

@jkotas is it expected that desktop COM metadata APIs throw BadImageFormat on x-plat cross-gen images or are we just calling them wrong?

[jkotas]

Yes, the desktop COM metadata reader is likely going to have problem with Unix x-plat cross-gen images.

[ericstj]

This PR would have fixed this by switching over to S.R.M, but we had more reasons than just perf for not taking it: #1215

One hacky/partial solution if we can't switch to S.R.M is to use the platform manfiest as a fast-path for this metadata. All of the problematic assemblies come from our platform package so we can apply the metadata from the manifest if the packageId is correct.