Incorrect publish output for netcoreapp1.1 on linux-x64 targets

[sbomer]

Repro steps

• Install preview2 SDK
• dotnet new console
• change TFM to netcoreapp1.1
• dotnet restore
• dotnet publish -r linux-x64 -c Release -o out

Expected behavior:
Either this works and the output has the required runtime assets (host, System.Private.CoreLib.dll), or this is not a supported scenario, and I get an error message.

Actual behavior:
Publish seems to succeed, but the published app contains no host or System.Private.CoreLib.dll. If I understand correctly, the linux-x64 rid isn't supported for netcoreapp1.1 targets, so the SDK should detect this and emit an error message.

@richlander @russellhadley

[livarcocc]

The SDK does not own the mapping of TFMs and RIDs. I believe that is between NuGet and the Microsoft.NetCore.Platforms target.

I am going to move the issue to NuGet initially, if that's not the appropriate location, please comment and tag me and I can follow up with the runtime team to see what else can be done. But in my mind, this should fail at restore time.

[livarcocc]

This issue was moved to NuGet/Home#6458

[livarcocc]

Re-activating as this is not something that is enforced by NuGet. The RID compatibility. However, I don't believe the SDK is the right place to contain this information either.

@ericstj @nguerrera @dsplaisted do you guys have any idea on how the SDK could prevent publishing for a RID not supported in a particular TFM?

[ericstj]

We already do this in the NETCoreApp2.0 package, which @nguerrera had to move into the SDK.
We do plan to enforce this in future versions of the NETCoreApp package. I think the SDK can go back and add the enforcement to the old versions by making @nguerrera's check apply to more TFMs.

[nguerrera]

My check will work for any .NETCoreApp version ~~~and it actually fixes the example here for .NETCoreApp 1.1. :)~~~

(EDIT: I was wrong about it fixing this specific case.)

[nguerrera]

Will be fixed by #1857

[livarcocc]

@nguerrera I just tried this and this seems to be working for 2.0 apps, but did not work for 1.1. At least I was expecting the scenario above to fail with a error message and publish succeeded.

[nguerrera]

I'll take a look

[ericstj]

My guess: in 1.x we had a more granular runtime.json. Using Linux-x64 is enough to get all the IL and get past Nick’s check, but it won’t get you the native bits (host, coreclr, shims, etc)

[nguerrera]

@ericstj's guess is correct. The check is sufficient to catch dotnet publish -r completely-invalid but not linux-x64 for 1.1. We are firing in more cases than before and there were no false positives introduced, but there are still false negatives for 1.x.

We would have to refine the check to look for specific RID-specific assets. It is currently based on the heuristic that there is at least one RID-specific package pulled in, but that's not sufficient to catch everything for 1.x.

[nguerrera]

Do we think it is worth refining the check for 1.x or can we say that flagging all invalid RIDs for 2.x+ and most for 1.x+ is good enough?

Changing milestone because it was chosen based on an incorrect assumption that it would be fixed for free with #1857.

[livarcocc]

I am going to close this issue as I believe the checks we have in place and the remaining life time for 1.x are enough.