NuGet restore in Visual Studio restores for multiple rids

[dsplaisted]

• In VS, create a new Console App (.NET Core)
• Wait for the NuGet restore to complete
• Inspect the targets in the obj\project.assets.json file

EXPECTED: A single section under targets for .NETCoreApp,Version=v1.0
ACTUAL: The following targets sections are also present: .NETCoreApp,Version=v1.0/win, .NETCoreApp,Version=v1.0/win-x64, and .NETCoreApp,Version=v1.0/win-x86

The main reason this is a problem is because it is different behavior than what happens when you do a command-line restore restore with the .NET CLI. Particularly, if you reference the System.ValueTuple package from a project targeting .NET Core 1.0, you will get package downgrade warnings in Visual Studio, but not if you do a command-line restore.

@natidea @emgarten @rrelyea

[srivatsn]

@emgarten should this move to the NuGet repo? I assume the PS is just nominating passing in the TF as NetCoreApp, version=1.0.

[emgarten]

I get the same warnings when using desktop MSBuild /t:Restore, and in that scenario the RIDs are coming from:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\NuGet\15.0\Microsoft.NuGet.targets

Is this build task suppose to be used for .NETCore projects? I was under the impression that it was only used for project.json and legacy csproj PackageReferences.

I don't know of anywhere that NuGet assumes RIDs during restore, the PS is most likely getting these RIDs from the target above and passing them along during the nomination.

Also, I'm not sure that the RIDs are the problem here. Leaving them off may cause this to fail at runtime.

[dsplaisted]

Also, I'm not sure that the RIDs are the problem here. Leaving them off may cause this to fail at runtime.

If the RIDs aren't added by default when using the .NET CLI, then that's the scenario we have the most test coverage of, so I wouldn't expect there to runtime failures if RuntimeIdentifiers is no longer defaulted.

[natidea]

I recall that back in October, the CLI removed it dependency on Microsoft.NuGet.targets which caused us to react with this PR to pull in properties that were missing as a result: dotnet/sdk#218

However, I don't think we ever removed it from VS/msbuild situations. Isn't this targets file authored in such a way that it is always available to all project types (i.e. because of the corresponding ImportAfter targets file)?

I'll inspect to confirm this is what is actually passing the RIDs to NuGet. I don't see NuGetRuntimeIdentifier or BaseNuGetRuntimeIdentifier in any of our Rules.