NUGet customization?

Question

I have a large number of projects on the go, and several solutions (which are subsets of the project "pool"). Sometimes it's nice to have a .sln just for specific testing.

Problems:

1. NUGet is tied to each solution individually.

2. NUGet likes to locate downloads in a "packages" folder off of the folder the .sln lives in. This is not ideal. I have a library folder for this kind of thing (one for all projects in the pool). I'm happy to have a NUGET subfolder off of this library area though.

I like the NUGet convenience, but I am not sure about it in large project solutions.

Possible answers:

1. One thought was to have a .sln & .csproj just for NUGET, and then reference packages as per normal. You lose some of the automation that way.

2. we don't add packages to source control, and say we recreate the project from source control, then nuget would download the exact same versions as required (messy)... and I don't even know if nuget works this way. This would require a high degree of trust to be placed upon the nuget payload provider. Not a good idea.

---

But in NuGet 1.4 we’re planning to make it integrated into NuGet. We will be adding a new feature to restore any missing packages and the packages folder based on the packages.config file in each project when you attempt to build the project.

http://haacked.com/archive/2011/04/27/feedback-request-for-using-nuget-without-committing-packages.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3a%20haacked%20%28you%27ve%20been%20HAACKED%29

... at least there's a way forward. Pity it's a mess for more than one solution with the same library folder.

Answer 1

I haven't tried this (the default NuGet operation works fine for me)... so it could be completely wrong (in which case my apologies).

The NuGet documentation includes a page about Using NuGet without committing packages to source control. Towards the bottom of the page, there are some examples of NuGet command lines that could be used in such scenarios and they all use -o [Package Directory] to specify where the packages should be dropped. In all the examples, the package directory is relative to the solution folder, but I strongly suspect that you could just as easily use an absolute path such as C:\Packages if you wanted.