Marko Apfel - Afghanistan/Belgium/Germany

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="&quot;$(ProjectDir)..\..\..\tools\Nuget\Nuget.exe&quot; install &quot;$(ProjectDir)packages.config&quot; -o &quot;$(ProjectDir)..\..\..\lib\NuGet-Packages&quot;" />
    <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:

1. Right click the project > Unload Project
2. Right click the gray unloaded project > Edit <project-name>.csproj
3. 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?”