NuGet update .sln file on adding packages

Jun 23, 2011 at 9:51 AM


I'm guessing this has been discussed before but I can't find the thread.

I'm working with NuGet the way it was originally designed, i.e. we add packages to the project and then we add these package binaries into source control. To make this easy to manage we create a solution folder, point it to a physical folder on the disk that is in the root of the solution directory, then add the binaries into the .sln file. e.g.

--> Binaries
        --> Runtime

This way, things get automatically added to source control and are downloaded by other developers. I'm not too concerned about the naming conventions, I'm ok to change that to make it easier but unless I'm missing an option in Visual Studio, for the number of package folders we might get, is a real PITA to have to create solution folders manually, point them to the correct place on the disk, then add the files manually to each solution folder. There doesn't seem to be any recursive "add everything under this location" to the .sln file in Visual Studio.

I'm I missing something or is this an option that can be added to the next NuGet release, maybe with an switchable default setting for those devs who don't really use .sln files or do not want to check into source control.

Thanks, Graham

Jun 23, 2011 at 11:09 AM

Hi bunceg,

With latest nuget, I think we don't need to add package binaries to the source control. We only need to add packages.config of every projects. Then, other developers can install all dependency packages using nuget command line. You can find more information on the nuget docs at this link,

If you really want to add dependency binaries to the source control, you can just add the whole packages folder.


Thanks, Soe Moe

Jun 23, 2011 at 5:06 PM

Here's the thread if you're interested:

Jun 23, 2011 at 10:38 PM


Thanks for the comments but I must be being a bit thick or missing something simple. Assuming I want to commit packages to source control (Visual Sourcesafe at the moment in our case), i.e to quote "The current NuGet workflow has always been to commit the Packages", then *how* do I do this in a way that is managable and that I can ensure I always have the latest versions when I download the solution from sourcecontrol?

To cause less friction for our developers, unless something has screwed up, all our source control management is done via Visual Studio. We get a sln file, we add files to the project and check-in through Visual Studio. Anything *not* at project level we handle through solution files.

As far as I can tell, the packages.config will get added to the project file automatically (and hence into Sourcesafe on checkin) but the packages will not as, correctly IMO, they are held at solution level and not added to the project file. This means they will not be added to sourcecontrol or maintained on a get latest etc. I have to leave my Visual Studio environment and add them manually through SourceSafe explorer.

I guess to get update or new packages added since the last time I did a "get latest" on the source code, I would have to use NuGet as I can't depend on Visual Studio as it doesn't know about the new/updated packages. I can't remember, but I presume NuGet warns me that new packages are required??


I'm just trying to work out the expected workflow if you *do* want to commit packages to source control and how to make this as frictionless as possible. I didn't spot any resolution to the issue from dfowlers thread....

Thanks again.