Motivation
Encouraged from the article “Using NuGet without committing packages to source control” I decided to wrap the NuGet-call in a MSBuild target instead of using a pre-build event.
Because we also trigger FxCop and StyleCop via targets this fits better in our project management.
Create the targets-file
First at all we need a targets-file for integration. It is located in a DevTree beside the NuGet-executable beneath a special tool-folder:

The content is quite simple:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<BuildDependsOn>$(BuildDependsOn);Nuget</BuildDependsOn>
<RebuildDependsOn>$(RebuildDependsOn);Nuget</RebuildDependsOn>
</PropertyGroup>
<Target Name="Nuget" BeforeTargets="CoreCompile">
<Message Text="Nuget for $(TargetName) starting." />
<Exec
Command=""$(ProjectDir)..\..\..\tools\Nuget\Nuget.exe" install "$(ProjectDir)packages.config" -o "$(ProjectDir)..\..\..\lib\NuGet-Packages"" />
<Message Text="Nuget for $(TargetName) finished." />
</Target>
</Project>
This is mostly the call from the denoted article enriched with some quotas to circumnavigate some problems with spaces we have at our Hudson/Jenkins Continuous Integration server.
The bunch of ..-folder navigation results from our DevTree-structure and must be adjusted to yours.
The makro $(ProjectDir) points to the folder in which the csproj-file is. Starting from this point you must navigate to the artifacts.
The attribute BeforeTargets="CoreCompile" concerns the time where the packages must be downloaded. CoreCompile is a target in the default targets-file in the csproj. So we should download the packages before this target runs.
Call the target-file
Next step is to modify the csproj-file that our new NuGet-target is called. To do this I prefer the following Visual Studio integrated way:
- Right click the project > Unload Project
- Right click the gray unloaded project > Edit <project-name>.csproj
- Edit the content to call the target
In my case the last lines look as following:

Here you can also see the calls to our other targets.
Run the logic
Now it is time to load the project again and try to build it.
And voila my output stated:

and the 3rd party library folder is enhanced with the NuGet-packages:

Update a package (package-usage)
If a new version of a package is available, this package should manually updated to the new version.
For this I use the Package Manager Console
Open the console: Tools > Library Package Manager > Package Manager Console
Set the correct package source (this took me hours, because a would update a package from a local source and the choice was “NuGet official package source”. I overlooked this choice.)
Update the package with update-package
Here is the result
How you could verify, the package is downloaded and the project-references are adjusted. This rocks!
Conclusion
NuGet allows the package management in a manner, that we could decide when we should update a package to a new version. Then NuGet adjusts the references in the projects we chose for update.
With a NuGet-MSBuild-target we got the chance to update the DevTrees at all involved machines – especially at continuous integration servers – without checkin the packages. It preserve the VCS-server from useless content.
Remarks
I configured NuGet so, that the packages are not located beneath the projects, but rather in solution-wide lib folder a little bit “higher” in the DevTree.
This is described here: “Is it possible to change the location of packages for NuGet?”