[Bug]: IVsPackageInstallerServices APIs sometimes throw ProjectNotNominatedException

[zivkan]

NuGet Product Used

Visual Studio Package Management UI, Visual Studio Package Manager Console

Product Version

VS 17.2 and higher

Worked before?

No response

Impact

No response

Repro Steps & Context

Note, this affects developers of VS extensions, not directly customers using VS (unless the extension calls the NuGet API and doesn't handle this scenario).

We detected this via telemetry, so I'm not entirely sure under what scenarios it happens (I was unable to reproduce, doing some quick tests). Anyway, VS extension developers can call into NuGet's IVsPackageInstallerServices APIs, but under (known) scenarios, it will throw a ProjectNotNominatedException (which is private/internal to NuGet, so extension developers need to catch InvalidOperationException). Before VS17.2, the same scenario likely also threw an InvalidOperationException, but the exception type & message might not have been so clear why.

This happens because of the way that CPS PackageReference projects work in Visual Studio. CPS is (or was) the Common Project System (now just called the Visual Studio Project System). The design, in order to reduce UI delays and do more work in parallel on background threads, is much more async than previous project systems. The flow is that the project system does the minimal synchronous project loading on the UI thread, then does more project loading on a background thread, then when it's ready it notifies NuGet about the project, and all relevant NuGet properties and items, via an API called IVsSolutionRestoreService3.NominateProjectAsync. Until this time NuGet doesn't know that the project supports Nuget, it doesn't know what TFMs the project has, it doesn't know which, if any, packages it references. Therefore, there's a lot of NuGet functionality, like GetInstalledPackages() that can't work until the project is nominated.

Note, there are APIs that allow extensions to get notifications that the project is ready, so extension developers should design their extension to handle this asynchronous nature of Visual Studio, even if it does make the code more complex. NuGet will stop collecting telemetry when this scenario is encountered, since it's, unfortunately, not actionable by us given the synchronous nature of the current APIs.

Verbose Logs

No response

[zivkan]

If there are VS developers who see this, I'd appriciate if you could give feedback about whether you prefer an async API to take a long time to respond, because it's waiting for a nomination (what should happen if the project has an error, and the project never nominates?), or if NuGet's async APIs should return immediately a status that represents that the project is not currently available?