Analyze the user gestures that defeat no-op, specifically clean-build & rebuild

[vsfeedback]

Context from @nkolev92

Analyze changing the user gestures that defeat no-op. Specifically the lack of a specific gesture to reevaluate the packages lock file and floating versions. Rebuild as a gesture seems counterintuitive.

The users probably never care about defeat no-op as gesture, rather think in terms of reevaluate floating or don't. They need a single way to force NuGet to throw away what it think it has and do it again (specifically, throw away cache file and reevaluate the assets file as necessary).

Original name: NuGet restore takes time on Rebuild when all packages are already restored
I have a solution with ASP.NET Core 2.0 proj, netstandard 2.0 lib, xamarin C# android app and several winforms projects. When I rebuild any of them I see "NuGet restore took 200ms-1.5seconds" in status bar. It happens even if all packages are already restored and package versions were not changed.

This issue has been moved from https://developercommunity.visualstudio.com/content/problem/261222/nuget-restore-takes-time-on-rebuild-when-all-packa.html
VSTS ticketId: 622567
These are the original issue comments:
(no comments)
These are the original issue solutions:
(no solutions)

[nkolev92]

There's a couple of things going on here.

NuGet has a caching mechanism to improve the performance of restore.
Whenever that cache gets hit in Visual Studio, it can range anywhere from 20ms to even a 1s or 2s depending on the project itself, the total number of projects in the solution, the machine etc.
Our goal is to keep it as low as possible, and we'd be happy if you can provide a repro solution for us to analyze and test abnormal performance.

Now on the second thing.
NuGet's caching mechanism can be defeated.
Please refer to https://github.com/NuGet/Home/wiki/NuGet-Restore-No-Op#usage for how.

In Visual Studio there are 3 ways to invoke restore.

1. Through the Restore Packages For Solution menu - This does not defeat the cache.
2. On Build - when calling build - This does not defeat the cache
3. On Rebuild - This defeats the cache.

This basically means that the slower performance of restore during rebuild is by design currently.

Now normally I'd close this as by design, but this is useful feedback for whether we need the on Rebuild restore should defeat the restore noop.

//cc @anangaur Useful feedback for the repeatable builds design.

[alex-belikov]

Thank you for clarifying the difference between Build and Rebuild, good to know!
The reason I mostly use Rebuild is that sometimes Build is not picking up latest changes I just did (and going to debug it for example). But that's a separate issue, I'll keep eye on it and will report if it will happen again.
An other point here is that my projects have not too many NuGets - from 2 to 6. If there were many than 1-1.5 seconds delay to check if they are still there on file system is understandable.
Overall pretty usable if Build will pick all the changes.

[nkolev92]

@alex-belikov
sometimes Build is not picking up latest changes I just did
I assume that by this you mean that the changes are not compiled? And not a NuGet related problem?

[alex-belikov]

@nkolev92
Yes, correct.

[nkolev92]

@alex-belikov

If you have scenarios where you consistently run into issues with incremental build, and you can provide a repro, I'd suggest filling an issue with MSBuild. The team there will be happy to help.

[StingyJack]

Is this the same for those who do Clean, Build ?

[nkolev92]

@StingyJack

In Visual Studio, clean - build will have the same NuGet behavior as rebuild, meaning it will defeat the cache.

This is not the case on the commandline (msbuild).
The reason for that is how it worked historically in VS and because from the commandline restore is not implicit on build, like it can be in Visual Studio.

[nkolev92]

Repurposing this issue as per the design in #9564 that addresses #9513.

The gestures that defeat no-op are not obvious.

[nkolev92]

perf triage: Assigning to @JonDouglas to understand whether we should be forcing a real restore upon rebuild.