'dotnet publish --no-restore --runtime X' fails when multiple RuntimeIdentifers are listed in the project file

[bergbria]

Repro

1. Create a .csproj with multiple <RuntimeIdentifiers> (e.g. <RuntimeIdentifiers>osx-x64;win-x64</RuntimeIdentifiers>)
2. dotnet restore
3. dotnet publish --no-restore --runtime win-x64

This will fail with

error NU1004: The packages lock file is inconsistent with the project dependencies so restore can't be run in locked mode. Please disable RestoreLockedMode MSBuild property or pass explicit --force-evaluate flag to run restore to update the lock file.

Automated repro

Download/unzip
publish_multi_rid.zip and run repro.bat

Additional context

• Omitting --no-restore will cause different package versions to be used than would be produced the by original dotnet restore. While being icky in general, this also causes breaks when NuGet lock files are used (e.g. Lock files prevent publishing when <RuntimeIdentifiers> is set NuGet/Home#8287)
• This seems vaguely related to NETSDK1061: The project was restored using Microsoft.NETCore.App version 2.1.6, but with current settings, version 2.1.0 would be used instead.  #2682

[nkolev92]

This bug breaks the only recommendation I could provide for repeatability (lock file) + publish.
Which is basically, 1 restore for all rids and then no-restore publish for each individual rid.

//cc @anangaur @rrelyea

[livarcocc]

@nkolev92 this happens exactly because of the issue we have been discussing regarding the implicit version for self-contained apps.

When you have runtimeidentifiers and you publish with a rid, we still treat your project as a framework dependent app and so use M.NC.App as the .0 version, like 2.1.0.

When you publish as a self-contained app (with runtime specified), you publish as a self-contained app and in that case we want you to be on the latest M.NC.App version possible, so you will be on 2.1.11, for example.

With the technology we currently have in place, this is unavoidable. I am not sure of a way around it.

[nkolev92]

Makes sense. Thanks @livarcocc

I guess 3.0 won't have the problem initially cause PackageDownload sha validation does not happen.
Related NuGet work item for that. NuGet/Home#7724

//cc @rrelyea

[nkolev92]

Related: https://docs.microsoft.com/en-us/dotnet/core/deploying/runtime-patch-selection

Namely there are things that can be done, they just move some responsibility to the app author.

[bergbria]

@nkolev92 / @rrelyea / @livarcocc - what's the state of this bug? Is there any rough timeline or line of sight on a fix?

My team needs to use lock files for compliance and other reasons. We'd really like to support cross-platform development as well but are currently blocked by this.

Given that lock files and the RuntimeIdentifiers property are both first-class citizens in modern .NET authoring, this feels like a higher-than-backlog priority to me (though I'm admittedly not familiar with other competing priorities).

[JustArchi]

@bergbria not sure whether this will help your use case or not, but for my project I've declared <TargetLatestRuntimePatch>true</TargetLatestRuntimePatch> globally in <PropertyGroup>, so the restore restores exactly the same version as publishing would. With that I'm using exactly the same publishing process in my CI, by calling a single dotnet restore then dotnet publish --no-restore for all of my declared runtime identifiers (and moreover, all publishes go in parallel).

The only "gotcha" with this is that if you also build generic (not self-contained) app, then it'll also require that runtime (or newer) for running it, and not just any 2.2.X. Not a problem at all if you're building only self-contained, and very little problem even if you don't, unless you want to explicitly support older runtimes with generic publish. Basically if you never intend to run your compiled app with older runtime than the one which compiled it, you can use this solution without any drawbacks, at least known to me.

[bergbria]

@nkolev92 / @rrelyea / @livarcocc - ping on my previous question about timeline/prioritization.

@JustArchi - thanks for info on the workaround! I don't think it will be sufficient for my team, though.

[bergbria]

@nkolev92 / @rrelyea / @livarcocc - ping...

What's the state of this bug? Is there any rough timeline or line of sight on a fix?

[livarcocc]

This will likely not get addressed before 5.0. Have you tried @JustArchi suggestion above?

[bergbria]

@livarcocc / @JustArchi - just to confirm, will TargetLatestRuntimePatch yield the same result over time if given the same global.json and an identical SDK install dir is specified in %PATH%? Or will it find the latest patch through a web service / machine installation dir?

[livarcocc]

For now, it will be reliable. Though, for self-contained apps, you should actually want to get the latest of the latest for that patch. That's the only guaranteed way your app will be as secure as possible.

[bergbria]

That workaround will work for my team for now as long as the result is stable. Our nuget lock files need to remain valid unless some source state changes.

[JustArchi]

@bergbria If the version of the SDK remains the same, yes, you're going to get reliable output, while newer SDK versions will appropriately bump the latest runtime patch up.