Builds triggered by DevKit features shouldn't restore all the time

[baronfel]

Describe the Issue

When I'm tethered on my laptop, or otherwise in degraded network connections, the builds triggered by DevKit to drive experiences like

• Test Explorer refresh
• Test Explorer build-before-test-runt

and more lean on the default behavior of the dotnet CLI, meaning they trigger a Restore. In degraded network conditions this restore is not likely to succeed, and so the entire experience is unusable due to what is seen as a failed build.

In addition, for larger repos Restore contributes significantly to the overall performance of even no-op, inner-loop builds. Here's an obfuscated binlog timeline for an internal partner repo. This repo has ~200 projects in it.

The green portion of this build is the Restore phase. This phase alone accounts for about half of all of the MSBuild Evaluations that occur during the overall build and ~20% of the overall build duration.

In an ideal world, DevKit would not do restores for 'inner-loop' builds and add --no-restore to these builds. DevKit should be aware of actions that do require a restore (modifying packages, manipulating project files, etc) and should handle restores behind the scenes (or allow a user to do an explicit restore).

Steps To Reproduce

1. Clone a dotnet-org repo, e.g. dotnet/msbuild
2. run build.cmd/build.sh
3. disable your network adapter
4. Open VSCode
5. perform a test explorer refresh or a test execution
6. Note that the failing restore blocks the workflow

Expected Behavior

In degraded networking conditions (or optionally in the usual course of test explorer discovery/execution) Restore should not be triggered so builds are more likely to succeed.

Environment Information

• OS: Windows
• VSCode Version: 1.103.0
• DevKit Version: 1.40.30-g4e486a3f24

[davidfowl]

+1, if we could be smart about not restoring all of the time. DevKit could prompt and ask me if I want to restore and then save that fact somewhere.