Package Manager is confused by centralized packages folder


I currently have NuGet Package Restore enabled and I'm using "repositoryPath" to store the packages for all the projects on my development machine in a single location.

NuGet Package Manager does not appear to be designed to handle this scenario properly.

When attempting to "Manage NuGet Packages for Solution", the installed packages list contains all the packages in my Packages folder, not just the packages that are currently being used by the projects in my solution. This causes various problems, such as packages that need updating not showing up in the Updates list.

If I attempt to manage packages at the project level (rather than for the whole solution), I also get strange behavior where sometimes no items appear in the Update list even though I know updates are available.

file attachments

Closed Jan 21 at 10:23 PM by jfritz
Closing as a duplicate of 2694 and is being fixed with the new kpm central repository featureset


feiling wrote Feb 12, 2013 at 12:21 AM

deepakverma wrote Apr 12, 2013 at 9:13 AM

reactivating as this is only fixed for the installed tab. online and update tab still shows packages that are not in the solution

dotnetjunky wrote Apr 12, 2013 at 12:51 PM

what packages and what versions? Online tab always shows all packages. Update tab should not.

deepakverma wrote Apr 12, 2013 at 6:55 PM

Any package. Online tab shows a green tick and update shows the package for updating.

dotnetjunky wrote Apr 13, 2013 at 1:25 AM

Move to 2.6 because the fix is not clean and it may affect perf

WayneBrantley wrote May 14, 2013 at 1:31 PM

After a while of using nuget and ending up with lots of old versions in the packages folder, the 'update' from solution shows lots of packages that need updating.

Clicking update on them brings up a window that has everything grayed out, because the update is not needed. Updating from project level correctly shows no update is needed.

Removing all packages from packages folder and then rebuilding (causing packages to be downloaded again) fixes it and the 'update' from the solution level correctly shows what really needs updated.

In this case, I am not using a single repository path for all solutions.

danbolger wrote Jun 22, 2013 at 1:52 AM

The issue description is a little ambiguous so here is a concrete example of a problem that is affecting us.

We have a very large application that has tens of solutions and hundreds of projects. We have Enabled NuGet package restore and manage packages at the solution level. We use a centralised packages folder which we specify by setting the repositoryPath in the NuGet.config file.

So I go to the first solution, go to the Online tab, search for my package, click the install button and select the projects I want that package installed to in that solution. After this is done, I have a local copy of the package in my shared packages folder.

Then I go to the second solution because I want to add the package there also. I open up the package manager dialog, go to the online tab, search for the package and when it is displayed in the search results, there is no Install or Manage button, and instead, I see a green tick indicating the package is installed. Yes the package now sits in my locally shared packages folder because of the work I did with solution 1, but no, it is not added to any of projects in solution 2, and I don't have a manage button so that I can add it to any of those projects.

To work around this, I have to use the Package Manager console and select each project individually in the drop down and execute Install-Package PackageName

Using NuGet version 2.5.40416.9020

stijnherreman wrote Sep 3, 2013 at 9:09 AM

Same issue as WayneBrantley here. Packages that are no longer used remain available in the "Updates" tab, and it's impossible to update the package for any project.

UberError wrote Nov 27, 2013 at 7:33 PM

Same issue here. Please patch.

shayneva wrote Jan 21 at 6:51 PM

This is a serious problem. Impact should be changed to HIGH

This bug results in NuGet thinking that a solution-level package is installed for all solutions which happen to share the same NuGet repository (the packages folder). This can happen if you have configured a shared NuGet repository for all of your solutions by setting it in a NuGet.Config file. A assume this is because NuGet looks in the shared NuGet repository to find packages and then assumes that every package there is installed in the current solution. What NuGet should do is look in the solution-level packages.config file (in the .nuget folder) to determine what packages are installed for the current solution.

When a shared NuGet repository is configured, NuGet command line will refuse to install a package if it is already in the repository (it returns an error saying that the package is already installed). The Visual Studio Package Manager extension will not show the package on the "Installed" tab, but on the "Online" tab it will show the package as already installed and not display the install button.

Furthermore, when opening a solution, the init.ps1 files for all the packages in the shared NuGet repository run - even if they are not installed for the current solution. This is absolutely outrageous!

One partial workaround for this problem is to first delete the package from the shared repository before opening the Visual Studio Package Manager extension, which will then show the package as not installed on the "Online" tab and it will display the install button. Although unfortunately because Visual Studio retains an open file handle on a package after installing, you will find that if you are working on mutliple solutions you are not always able to delete the package from the repository, and will need to close Visual Studio completely in order to release the file handle in order to do so.

Another partial workaround for this problem is to hand edit the solution level packages.config file (in the .nuget folder) and manually add the required package xml element, and then open the Package Manager Console in Visual Studio which causes it to run the init.ps1 file in the tools folder of all packages found in the shared NuGet repository. However, Visual Studio will only do this once per running instance, so if you need to do it again you will have to close Visual Studio completely and open another instance.

What's more is that these workarounds will only help to install the package. They don't help with the problem that when uninstalling the package for one solution, it removes the package folder from the shared NuGet repository resulting in other solutions needing to restore it again. Furthermore, updating packages that you have installed using either of these workarounds is also impossible using the Visual Studio Package Manager extension.

Due to this problem, I have now given up on having a shared centrally located packages folder and the result is that I now have scores of the same packages duplicated across my hard drive, wasting several gigabytes of space, not to mention the waste of time in have to download them all several times.

Its an absolute disgrace that this bug has existed and hasn't been fixed in over 2 years!

Related to workitem: https://nuget.codeplex.com/workitem/2694