Runtime conflict resolution doesn't exclude System.Linq when RuntimeIdentifiers is set

[eerhardt]

Extract the following
ConflictBug.zip

dotnet restore App
dotnet run -p App\ConflictBug.csproj

Expected result:
The app should run fine.

Actual result:

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'System.Linq, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
   at ConsoleApp.Program.Main(String[] args)

Looking at the .deps.json file, the "runtime" sections aren't getting removed for System.Linq, System.Linq.Parallel, etc even though these files are in the shared framework.

If I remove the line <RuntimeIdentifiers>win7-x64;win7-x86;osx.10.11-x64;ubuntu.14.04-x64;ubuntu.16.04-x64;centos.7-x64;rhel.7.2-x64;debian.8-x64;fedora.23-x64;opensuse.13.2-x64;osx.10.10-x64;rhel.7-x64</RuntimeIdentifiers> from the .csproj, the app executes fine.

/cc @ericstj

[ericstj]

Which CLI should I be using?

[eerhardt]

I used a locally built one from dotnet/cli/master. But the latest from https://github.com/dotnet/cli/tree/master#installers-and-binaries should work.

[ericstj]

Bug is here: https://github.com/dotnet/core-setup/blob/master/pkg/tasks/GenerateFileVersionProps.cs#L87

The reason I did this was to address the case where we're building a shared framework app and don't have the runtime-specific packages in the view. I thought the only case that'd happen was when RIDs aren't set since that's how nuget3 targets worked, but it looks like the CLI is using the RID-less target for execution even for a standalone app.

[ericstj]

To workaround this you can edit .nuget\packages\microsoft.netcore.app\2.0.0-dev-eng-001308-00\build\netcoreapp2.0\Microsoft.NETCore.App.props
from

  <ItemGroup Condition="'$(RuntimeIdentifer)' == '' AND '$(RuntimeIdentifiers)' == ''">
    <PackageConflictPlatformManifests Include="$(MSBuildThisFileDirectory)Microsoft.NETCore.App.PlatformManifest.txt" />
  </ItemGroup>

to

  <ItemGroup Condition="'$(RuntimeIdentifer)' == ''">
    <PackageConflictPlatformManifests Include="$(MSBuildThisFileDirectory)Microsoft.NETCore.App.PlatformManifest.txt" />
  </ItemGroup>

[GSPP]

I'm tracking related issues and information in a list. They are related to System.Net.Http, System.Runtime, System.IO, System.ValueTuple, System.Buffers and others.

https://github.com/dotnet/corefx/issues/32587
https://github.com/dotnet/corefx/issues/32561
#481
#567
#558
#887
#891
https://github.com/dotnet/corefx/issues/32610
https://github.com/dotnet/corefx/issues/30642
https://github.com/dotnet/corefx/issues/32757
#895
#877
#521
#295
#476
#184
#936
#941
https://github.com/dotnet/corefx/issues/33148
NuGet/Home#7440
https://github.com/dotnet/corefx/issues/31532
https://github.com/dotnet/corefx/issues/22781
https://github.com/dotnet/corefx/issues/23306
https://github.com/dotnet/corefx/issues/29622
https://github.com/dotnet/corefx/issues/9846
https://github.com/dotnet/corefx/issues/17522
https://github.com/dotnet/corefx/issues/25773

All of these have the same very few underlying issues.

.NET 4.7.2 helps with some but not all of these. You can look at my comments on some of these issues for some ideas on how to work around those problems. I also have a central list of ideas to try.