Make default RIDs consistent across platforms

[zivkan]

Is your feature request related to a problem? Please describe.

NuGet has a feature called "Repeatable Builds", which is really a lock file that lists every package version and package hash used. When restoring on a different machine, it's possible to use "locked mode" which will fail the restore if the package graph is different, and this has been a way to mitigate "package confusion" or "package substitution" attacks since before that became widely publicized in 2021.

Some customers using this feature are confused why NuGet is failing when the same project is restored on Linux vs Windows:

• Forced locked mode doesn't work cross platform NuGet/Home#9195

Its root cause is when the .NET SDK adds the win7-x64 or win7-x86 RID, but on Windows only:

sdk/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.RuntimeIdentifierInference.targets

Lines 55 to 62 in 4bb25c3

	<PropertyGroup Condition="'$(TargetFrameworkIdentifier)' == '.NETFramework' and
	'$(HasRuntimeOutput)' == 'true' and
	$([MSBuild]::IsOSPlatform(`Windows`))and
	'$(RuntimeIdentifier)' == ''">
	<_UsingDefaultRuntimeIdentifier>true</_UsingDefaultRuntimeIdentifier>
	<RuntimeIdentifier Condition="'$(PlatformTarget)' == 'x64'">win7-x64</RuntimeIdentifier>
	<RuntimeIdentifier Condition="'$(PlatformTarget)' == 'x86' or '$(PlatformTarget)' == ''">win7-x86</RuntimeIdentifier>
	</PropertyGroup>

Describe the solution you'd like

While this can be mitigated by customers adding <RuntimeIdentifier>win7-x86<RuntimeIdentifier> in their own project fie, it would be great if the SDK was consistent across platforms. I assume that the $([MSBuild]::IsOSPlatform(Windows)) condition is added for some legacy compat reason, but I really can't guess why or what benefit it brings. Would it be "harmful" if the SDK either stopped adding this RID on Windows, or alternatively added it on Windows when all the other conditions (TFI==.NETFramework, etc) are true?

I'm not sure under what other scenarios the SDK adds specific RIDs, or PackageReferences, but I think the implicit PackageReferences have mostly gone away since PackageDownload was added.

If RIDs and PackageReferences can't be consistent by default across platforms, then guidance or recommendations on how to make the SDK more "determinstic" that that NuGet's lock files can be used would be appreciated. While I could document "specify you own RIDs" as something that "worked for me", I don't know if this would introduce different problems.

Additional context

[aortiz-msft]

To provide some context on this issue, this is one of the most upvoted bugs in the NuGet client repo: NuGet/Home#9195.

[baronfel]

We do this for some windows-API reason - @dsplaisted do you remember the history here? I know we've looked at this area recently with the non-portable RID graph change.

[dsplaisted]

I imagine when this was first added we added the IsWindows check because it wouldn't have made sense to use Windows RIDs on Mac/Linux where targeting .NET Framework probably meant targeting Mono. That's less the case now, so I'd support removing that check in order to make NuGet repeatable builds work better (with the right breaking change / change wave / major version introduction).

[eatdrinksleepcode]

This problem was reported in Nuget 4 years ago. I just experienced it again today.

Really puts a dent in the ".NET is cross-platform now!" argument when basic stuff like this doesn't work for so long.

[baronfel]

So if we were looking for a 'safe' way to alter this behavior, we could potentially add another condition to the guard here:

If the project has been configured to use NuGet Lock Files then do not automatically modify the Runtime Identifiers

From the NuGet docs, the primary configuration knob used to signal opt-in is RestorePackagesWithLockFile. So we could add the following condition:

$(RestorePackagesWithLockFile) != 'true' and

to the existing logic and that would safely opt-in.

[zivkan]

While the RID list isn't an "analysis", maybe it's worthwhile considering changing the default via the new SdkAnalysisLevel. Note this is just a superficial gut reaction, I haven't thought through whether different RID defaults on different SDK versions is a good or bad idea, just something that is technically feasible.