Home: Bad configuration causes restore to fake succeed in VS/fail with a null pointer exception.

[donnie-msft]

Details about Problem

See https://github.com/NuGet/Home/issues/8375#issuecomment-728659420

Bad configuration can cause restore to throw a fit :)

~Currently we have a non-consistent repro reported by @agr where modifying the csproj externally, and changing a PackageReference version, a No-Op restore happens, when a package upgrade is expected.~

~Interesting note:
When the issue reproduces, running Get-Package in PMC mitigates it. After that command restore works as expected. Command produces expected output (i.e. versions listed there match the contents of .csproj).~

~NuGet product used (NuGet.exe | VS UI | Package Manager Console | dotnet.exe):~

~NuGet version (x.x.x.xxx):~

~dotnet.exe --version (if appropriate):~

~VS version (if appropriate): VS Enterprise 2019 16.3.0 Preview 1.0 [29118.114.d16.3]~

Detailed repro steps so we can see the same problem

~(inconsistent repro)~

~1. git clone https://github.com/NuGet/NuGet.Jobs.git;

1. Open solution in VS;
2. While VS is running, edit src\Validation.Common.Job\Validation.Common.Job.csproj in external editor: specify NuGetGallery.Core's version to be 4.4.5-agr-stg-folders-2873446. Save file;
3. Go back to VS, it suggests reloading projects, reload all;
4. Right click solution, select "Restore NuGet packages".~

[nkolev92]

This sounds weird.
If it turns out to be a bug, it can be 2 things:
The DependecnyGraphContext is somehow not refreshed on NuGet side.
The old project system is reporting outdated references.

When the issue reproduces, running Get-Package in PMC mitigates it. After that command restore works as expected. Command produces expected output (i.e. versions listed there match the contents of .csproj).

Then how did we verify that a no op happened for that project in the first place?
Did we look at the assets file? Look at the dependencies node in the sln manager?

[donnie-msft]

Maybe my terminology is too strong. I'm calling it No-Op because it told Andrei that all packages were up-to-date.

//cc: @agr Can you look at the places Nikolche mentioned next time you have a repro?

[agr]

When it repros the error message is:

All packages are already installed and there is nothing to restore.
Time Elapsed: 00:00:00.4219789
========== Finished ==========
Error occurred while restoring NuGet packages: Object reference not set to an instance of an object.

So, it's not just no-op.

[nkolev92]

All packages are already installed and there is nothing to restore.

This usually means that only packages.config projects were found. messages for PR are different.

Error occurred while restoring NuGet packages: Object reference not set to an instance of an object.

This is our culprit. Something went wrong during the PR restore.

Does restoring again hit the same issue or you didn't try that?
I'm basically trying to figure out if something is out of date and it hit an NPE, or if once we hit that NPE, we keep hitting it.

[agr]

Restoring repeatedly fails until I run Get-Package in PMC or restart VS. Closing and reopening the project does not help.

[nkolev92]

If you hit this again, can you enable high verbosity? It will help us understand where exactly the exception occurs.

https://blogs.msdn.microsoft.com/saraford/2008/10/07/did-you-know-you-can-configure-the-msbuild-verbosity-in-the-output-window-329/

[agr]

Got it again, detailed log: Output-PackageManager.txt

[agr]

With @joelverhagen's help I think we found the cause:

    <add key="Dev.nugettest.org" value="https://apidev.nugettest.org/v3/index/json" />

in global nuget.config was causing it. When I put the correct URL there, it started to restore fine.

[nkolev92]

I think this is a great investigate/intro bug for anyone interesting in restore :)

Retitling.
Reproducible on commandline as well!
8375.zip