RestoreLockedMode=true & RestoreForceEvaluate=true should error

[nkolev92]

Currently that's not the case.

Repro steps

1. dotnet new classlib
2. Enable lock file
3. dotnet restore (generate lock file).
4. dotnet restore /p:LockedMode="true"
5. dotnet restore /p:LockedMode="true" /p:RestoreForceEvaluate="true"

The last one should fail, as the instructions do not make sense.
From skimming the code, RestoreForceEvaluate takes precedence.

https://github.com/NuGet/NuGet.Client/blob/bdcec93681afdd1f5cd553af07414a3b3d9a866c/src/NuGet.Core/NuGet.Commands/RestoreCommand/RestoreCommand.cs#L462

//cc @anangaur
It's a trivial fix, so prioritize if you see a need for it.

[anangaur]

Agree. But based on the options semantic meaning, shouldn’t it fail only if there needs to lock file update/modify?

[nkolev92]

They feel like different commands :) Personally think error is better. Do we see a scenario where doing this makes sense?

Regardless though, currently the behavior is respecting ForceEvaluate and not considering RestoreLockedMode, which is counter to both our expectations.

[anangaur]

They feel like different commands :) Personally think error is better. Do we see a scenario where doing this makes sense?

There is a corner case but I think for now, an error should be good enough.

[anangaur]

Just to add /p:LockedMode="true" is the repeatable build promise on CI/CD machines and should not be broken. Hence I feel we should just fix this asap.

[nkolev92]

fyi @rrelyea

//cc @NuGet/nuget-client If anyone is interested in taking this in week 3.
It's a simple fix, but a nice entry into the lock file/PR restore space.

[nkolev92]

@cristinamanum

As I know you've been familiarizing yourself with lock file stuff, here's a lock file bug, that you can look into.