Need to support additional restore options when restoring for a RID in self-contained publish

See https://github.com/dotnet/cli/pull/4286#pullrequestreview-2420079

When we are calling dotnet restore3 when publishing for a self-contained app, we are not passing in any extra options to restore3. This can be an issue for users who call restore with specific properties. When we call restore, it will be overwriting the project assets file that was originally restored.

Some options for supporting this:

1. Pass ExtraMSBuildArguments into both the restore call and the publish call.
   • This can have issues if you explicitly need different values for the two MSBuild calls.
2. Come up with another way to take both “extra restore args” and “extra publish args” separately in one command-line.
3. The user can use environment variables to set any properties they want passed into MSBuild /t:restore.
4. Save the arguments passed into dotnet restore3 orginally, and read them during publish’s call to restore.
5. The user explicitly restores with the RID + extra restore options before calling publish. Then we add a new option to dotnet publish3: --no-restore, which allows publish to use the previously restored assets file, with the RID in it.

@emgarten @blackdwarf @piotrpMSFT @livarcocc @brthor

[eerhardt]

Could the publish target’s dependency on the restore target be modelled in the publish msbuild task itself?

Unfortunately, no it can’t. This is because “restore” will install .props and .targets files into your project. But if restore happens in the same MSBuild invocation as ‘publish’, those new .props and .targets files will not be honored/loaded/used. In order to get the correct behavior, you always need to restore in a separate MSBuild invocation than when running targets that can be affected by restore.

(note the 2 properties needed for the RID):

Thanks for pointing this out. @emgarten has fixed it so the Restore target would also honor /p:RuntimeIdentifier. See https://github.com/NuGet/NuGet.Client/pull/927.

[blackdwarf]

@eerhardt thanks for the more detailed explanation. Based on the above, I see that P2P references and restoring them for a given RID was the major reason this backing out was done?

While it is true that not having type: platform is more towards the goal we wanted, this solution still requires changing your project. With this in mind, we cannot really say that our goal has been met.