When I go to "Manage Nuget Packages for Solution" I only see the installed pacages for one of my projects in the Installed Packages tab. I see the same list im the Package Manager Console using Get-Package. The project that i see packages for is the first project listed in Pckages/repositories.config:

<?xml version="1.0" encoding="utf-8"?><repositories>  <repository path="..\RequestReduce.Facts\packages.config" />  <repository path="..\RequestReduce\packages.config" />  <repository path="..\RequestReduce.Facts.Integration\packages.config" />  <repository path="..\RequestReduce.SampleWeb\packages.config" />  <repository path="..\RequestReduce.SqlServer\packages.config" />  <repository path="..\RequestReduce.SassLessCoffee\packages.config" /></repositories>

All of the packages.config files listed in repositories.config exist where they are supposed to be and each .csprog file has a reference to it. The contents of each packages.config looks ok.

As an experiment, I added a package in the package manager to one of my other projects that I already had. Instead of getting the Nuget Install dialog with the progress bar that moves as the package installs, I immediagely got the green checkbox next to the package in the package manager. I keep all of these files in source control here: https://github.com/mwrock/RequestReduce after the already installed package magically showed up after adding it. There was no change to any of these files in my locally uncommited changes so I'm not sure where this is all being tracked.

I have had issues in the past with installed packages disappearing unexplainably. I'd like to better understand this issue or know if its a bug, In the past I have dealt with this by blowing away the packages.config and recreating it by readding the packages but I have so many packages now that process is becoming laborious

Any Thoughts?

Thanks.

Sure sounds like a bug to me. I tried to see if have the same problem with a few of my multi-project solutions, but it worked as I expected. Triage team, maybe we can have Alex see if he can repro this?

OK. Last night I pulled down the nuget repo and started what I thought was going to be a bug fix this morning. After a good cry when I realized that the package repo was implemented as a Linq provider, I discovered that the repo discovers physical local files by the presense of .nupkg files in the root of each package folder. I actually have *.pkgfiles in my git ignores list since I don't care to keep the .nupkg files that I generate for my own projects and didn't realize that these were the key to nuget.exe finding packages I install through the IDE. This explains why this randomly happens to me since these files often stay around for awhile until I start moving between branches and pulling pushing repos between different boxes.

So it sounds like this is not a bug per se. I'll adjust my ignore list to only ignore the nupkg files that I create. Might be a good idea to document that this is how nuget finds packages. I have run into one other person with this same problem and if this is documented, its not very discoverable. Perhaps it would be better to use something else as a means to discovering packages. After installing a package, the nupkg file is not really needed at least to my knowledge and for most use cases. However, my guess is that the notion of "repository" holds not just for a nuget feed that is consumed by VS and other tooling but also the private repo of packages that lie on a user's disk installed with VS. While the nupkg may not be so important to the latter, I'ts crucial to the former. Certainly different repo implementations could use a different extension or convention of finding packages but I'd think that's pretty low pri compared to other features in your back log.

Anyhoo, I am soothed my a mild sense of satisfaction now that I know why my packages become mysteriously invisible to VS and that there is now something I can do to make it stop.

Thanks

One final note. I just implemented the automatic package restore feature and realize that would have solved all of this. Very slick feature that I underestimated before actually using it.

I'm glad it's all working for you now, but I'm surpised the presence of .nupkg files (or lack thereof) is how we handle this. Since it's all working, though, and I haven't seen other hit this problem, I don't think we'll investigate further, at least yet.