Best way to work with Nuget in C# solutions

Topics: General
Apr 7, 2013 at 7:08 AM
Edited Apr 7, 2013 at 7:47 AM

I have wrote here before what are we trying to do and although there some issues I can't solve there's a workaround for almost everything.
What am I trying to do is as follows:
1) Use only one folder for packages for all the solutions in my working copy (There at least 200 of them)

2) Use one nuget.targets, one nuget.config and one nuget.exe for all solutions.

So far, I have been using a pre build event that updates and installs packages for each solution. I have tried to move the pre build event into a common .targets file that all solutions are using but for some reason it failed to work sometimes.
After a short investigation we have found out that we can add the update and the install commands into the nuget.targets file. That worked just fine but now, when I try to install a certain package version using nuget.exe install <package ID> -version <certain version number> it always upgrades the package to its latest version.

What I'm trying to find out is what is the most common/reasonable/preferable way to work?


I'm also trying to find out if there's a way to prevent the .csproj files from being changed whenever a package is being upgraded?

Apr 7, 2013 at 1:37 PM
Starting from NuGet 2.1, you can use hierarchical nuget.config and explicitly specify 'packages' folder location.

That should remedy some of your pains, if not all.
Apr 8, 2013 at 7:11 AM
Thanks lextem

We've managed to use only one folder for packages.

Basically, it looks like we are in the final stage of our project. The only thing that is still hasn't been solved is the issue with the exclude version flag.
This flag works just perfect but I need it to work only for some of the packages in our projects.
I know that I can run the nuget install command for one package at a time but I prefer to keep it as it is today and run it for a package.config file for each project. What I'm missing is an exclude version parameter that can be added to a packages.config line.