Migrated class library project targeting netstandard16 and netstandard13 gives 'no run-time assembly compatible' errors

[kierenj]

Steps to reproduce

Have a migrated csproj file thusly:

<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">
  <PropertyGroup>
    <Description>MyProject here</Description>
    <VersionPrefix>0.2.0</VersionPrefix>
    <TargetFrameworks>netstandard1.6;netstandard1.3;net451</TargetFrameworks>
    <RuntimeIdentifiers>win7-x64;win7-x86;osx.10.10-x64;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</RuntimeIdentifiers>
    <AssemblyName>MyProj.Redacted.Here</AssemblyName>
    <Features>IOperation</Features>
  </PropertyGroup>
  <ItemGroup>
    <Compile Include="**\*.cs" />
    <EmbeddedResource Include="**\*.resx" />
    <EmbeddedResource Include="compiler\resources\**\*" />
  </ItemGroup>
  <ItemGroup Condition=" '$(TargetFramework)' == 'netstandard1.6' ">
    <PackageReference Include="NETStandard.Library">
      <Version>1.6.1</Version>
    </PackageReference>
  </ItemGroup>
  <ItemGroup Condition=" '$(TargetFramework)' == 'netstandard1.3' ">
    <PackageReference Include="NETStandard.Library">
      <Version>1.6.0</Version>
    </PackageReference>
  </ItemGroup>
  <ItemGroup Condition=" '$(TargetFramework)' == 'net451' ">
    <Reference Include="System" />
    <Reference Include="Microsoft.CSharp" />
  </ItemGroup>
  <PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
    <DefineConstants>$(DefineConstants);RELEASE</DefineConstants>
  </PropertyGroup>
</Project>

Note, the project has but one class, Placeholder.cs, which is entirely empty.

Expected behavior

Project builds correctly, three targeted frameworks.

Actual behavior

Many errors in this form:

C:\Program Files\dotnet\sdk\1.0.0-preview4-004233\NuGet.targets(70,5): error : System.AppContext 4.1.0 provides a compile-time reference assembly for System.AppContext on .NETStandard,Version=v1.3, but there is no run-time assembly compatible with centos.7-x64. [C:\git\kierenj\my-project-name-redacted\whatever.sln]

(For pretty much every System.* package)

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview4-004233)

Product Information:
 Version:            1.0.0-preview4-004233
 Commit SHA-1 hash:  8cec61c6f7

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.14393
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\1.0.0-preview4-004233

Would appreciate any tips for progressing. This is the latest in a chain of about 6 bugs and workarounds for bugs I'm deeply immersed in, trying to build a workaround environment for my project. Let me know if I've got the wrong repo, too.

[lukasz-pyrzyk]

Did you run dotnet restore after migration?

[kierenj]

Yes, very many times :) This is after a few hours of work to try to track down what might be the cause

[dasMulli]

@kierenj does it work if you just remove / comment out the RuntimeIdentifiers property?

@livarcocc Maybe RuntimeIdentifiers should only be emitted if the project.json has "emitEntryPoint": true? I'm seeing the same error if I migrate a lib that targets both netstandard and full framework.

[livarcocc]

We need the runtime identifiers if the project target any full framework project. Even a library.

[dasMulli]

That is.. unfortunate..
NetStandard.Library cannot be restored if RuntimeIdentifiers is set and if you condition RuntimeIdentifiers on the target framework, no runtime assets are restored and project.assets.json doesn't contain entries for the RIDs.

[ThadHouse]

I'm running some migrations on my repositories, and running into this issue too. However if I do delete the runtime identifiers, it starts working again. I am building both a .NET 4.5 and a .NET Standard 1.5 project in most of my repos. So I'm confused on the runtime identifiers statement for targeting the full framework, as I'm not seeing that issue.

[dasMulli]

@livarcocc why exactly does a library need the RIDs? I'm a bit lost on that at the moment..
If so, that looks kind of blocking.. e.g. aspnet/ef seem to do it without RIDs (just saw an issue by @natemcmaster #614)

[livarcocc]

I actually didn't realize this wasn't needed for libraries. I will try this here and fix migration to not add them when the output type is a library.

Thanks for educating me on this.

[TheRealPiotrP]

Thanks @jgoshi

[nathanielcook]

@dasMulli @livarcocc Feel free to chime in on this conceptual question if you have a good understanding about that topic now.