Lock files prevent publishing when <RuntimeIdentifiers> is set

[bergbria]

Details about Problem

dotnet.exe --version (if appropriate): 2.2.300 and 3.0.100-preview5-011568

Automated repro

Download/unzip restore_multi_RID_repro.zip and run repro.bat

Detailed repro steps so we can see the same problem

1. Create a csproj with multiple RIDs specified in <RuntimeIdentifiers> (e.g. <RuntimeIdentifiers>osx-x64;win-x64</RuntimeIdentifiers>)

2. dotnet restore --use-lock-file

At this point, simply running dotnet publish won't actually create self-contained applications (e.g. a .exe file for windows). This is annoying, but not really Nuget's fault.

Normally, this would be resolved by running dotnet publish -r win-x64. However, this will actually mutate the lock file that was just generated.

If I enable locked mode in the publish command (this really should be a top-level flag, btw) via dotnet publish -p:RestoreWithLockFile=true -p:RestoreLockedMode=true -r 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

Effectively, publishing doesn't play nicely with lock files when multiple RuntimeIdentifiers are in the csproj.

Presumably there's something in the restore target that looks at the <RuntimeIdentifier> property and discards <RuntimeIdentifiers> if it's set.

[nkolev92]

Since packages can contain architecture and platform specific assemblies, rids affect restore and the packages downloaded.
https://docs.microsoft.com/en-us/nuget/create-packages/supporting-multiple-target-frameworks#architecture-specific-folders
Each rid/tfm combination needs to go through the asset selection/dependency resolution process.

The self contained publish is effectively changing the restore inputs, and since the intermediates are shared, restore fails.

Not sure what our long term strategy is, as that will involve SDK/CLI people (@livarcocc), but for now, as a workaround you can do the following;

1. Include all rids in the project file.
2. Publish with no restore. dotnet publish -r win-x64 --no-restore in this case would just use the generated target graph for that rid in the full multi rid restores. Since the results for the specific target are exactly the same, this does not cause any issues.

[bergbria]

@nkolev92 - this fails with the same error whether or not I pass --no-restore

1. dotnet restore --use-lock-file
2. dotnet publish -p:RestoreWithLockFile=true -p:RestoreLockedMode=true -r win-x64 --no-restore

[nkolev92]

edit: Not sure what that first sentence was, lol :D

Does the 2nd step fail?

That should not trigger restore at all. So I'd imagine there's something else going wrong.

[bergbria]

@nkolev92 - yes, I'm sure. I've captured a diagnostic .binlog of the failed build and am attaching it here. (Note that I had to change the extension to .zip to make github happy, You'll want to rename before opening). publish_multiRID.zip

It's specifically failing in the ResolvePackageAssets target, which is run due to ResolveLockFileReferences, which gets hooked into the dependsontargets for ResolvePackageDependenciesForBuild, which is depended on by ResolveAssemblyReferences. None of those seem to be conditional.

[nkolev92]

Due to legacy reasons the ResolveLockFileReferences target actually refers to the assets file.

So as expected the restore operaton itself is not running, however the SDK error seems weird.
Not sure why that would be happening.

Does dotnet build --no-restore work?

[bergbria]

It works if I run restore first; else not.

[nkolev92]

oh, my bad, that was unclear.

So you have to run 1 full restore with all the rids and then just publish for each rid individually.

[bergbria]

Summary of behavior:

1. publish -r --no-restore
   a. "NETSDK1061: The project was restored using Microsoft.NETCore.App version 2.1.0, but with current settings, version 2.1.10 would be used instead."
   b. manifests with or without nuget lock files
2. publish -r
   a. no error without nuget lock files
   b. with nuget lock files
   1. with -p:RestoreLockedMode=true
      a. error NU1004: The packages lock file is inconsistent with the project dependencies so restore can't be run in locked mode
   2. without that
      b. succeeds but overwrites packages.lock.json

#1 seems like a bug in the dotnet sdk. Logged dotnet/sdk#3383 for that.