Home: NuGet restore won't remove packages from project when no PackageReference items exist

[AArnott]

VS version (if appropriate): 16.1 Preview 3 (28902.138.d16.1)

Detailed repro steps so we can see the same problem

1. Create WPF application
2. Add to Source Control (git)
3. Create new branch "analyzers"
4. Install-Package Microsoft.VisualStudio.Threading.Analyzers
5. Save All
6. Commit changes in Team Explorer
7. Switch branches to master

Expected

The analyzer package is removed from the project.

Actual

The analyzers still appear in Solution Explorer.
Forcing a Nuget Package Restore on the solution doesn't remove them.
Running nuget.exe restore on the solution doesn't remove them.
A Rebuild doesn't remove them.

Only manually cleaning out the obj folder and reloading the project gets rid of the analyzers.

[AArnott]

I believe the reason for this is that in the change branch, the only PackageReference in the project was removed, so nuget incorrectly believes no package restore is required. It leaves the old project.assets.json file and the rest of the nuget artifacts in-place, which still reference the analyzers package.
Clearing out the obj folder removes the nuget artifacts and thus solves the problem (although evidently the project system isn't watching for changes there so reloading is required for it to notice).

I believe nuget restore should clean up old restore artifacts for projects that it finds no PackageReferences in.

[tbolon]

I agree with that. As a workaround, at least the "Clean" target should remove the project.assets.json file which is causing problems.

We have similar projects when migrating from PackageReference/packages.config with different branches: each time we need to switch between branch, we have to manually remove all obj folders for VS to work.

[nkolev92]

Related tracking issue on project-system side: https://github.com/dotnet/project-system/issues/3164

@tbolon The clean target deleting the assets file is not really an option we can consider.
The project that created the assets.json is a different one from the one then loaded in VS. So that project wouldn't know. It'd be illegal for the clean target to delete something it did not create in the first place.

Furthermore as far as deleting the assets file in the general scenario goes, this will lead to tricky scenarios, as msbuild /t:build does not implicitly run restore. So /t:rebuild would always fail for PackageReference based projects.
Note that this would also completely change the references and it would lead to a "squiggly" experience in VS until restore has run. Considering that restore cna be disable, it is suboptimal.

[AArnott]

The project that created the assets.json is a different one from the one then loaded in VS.

@nkolev92 I agree with everything you said, except the statement above. This doesn't make any sense to me. Which project created the project.assets.json file if it isn't the project to which that file applies?

[nkolev92]

I'm suggesting that the project.assets.json applying to the now packages.config based project is the issue.

The packages.config project should not be cleaning up a project.assets.json file generated by the PackageReference project.

My analogy is the following.

• Create a basic project.
• Build
• Go into bin/obj and copy a.dll to b.dll.
• Run clean

The b.dll will still be there.

As far as the packages.config project is concerned the project.assets.json is equivalent to b.dll.

[nkolev92]

cc @jeffkl @aortiz-msft, the issue tracking the problem we discussed.