NuGet Developer WorkFlow

During the proof of concept of migrating our internal dependency resolution from SVN Externals to NuGet I forgot an important stakeholder; Developers.  🙂

When the build updates the packages; how does a developer ensure their environment is up to date?

Edit: There is now a NuGet PowerTools Package that will add a PackageConsole command to restore all packages.
I still like the TortoiseHook and still wish I could specify the packages location, but we’re getting closer to ‘there’.

Check In Packages

The obvious answer is to check in the packages. After all that’s how the SVN Externals solution worked and it ensures the repeatability tenant of continuous builds. Sometimes however it’s not an option for a number of reasons; company policy, ruthless team leads or dictating architects, take your pick.

Check In Packages to a “temp” repository.

The way our SVN externals solution worked was to keep a separate repository entirely for “packages”. This repository could be blown away when it got bloated and replaced by a new version. Because it was used for multiple solutions/Company projects, it also enabled remote workers to keep their own copy of the repository locally (using DNS or host file entries).

This method can still be used with NuGet and means that an SVN update updates everything.

Pre-Build Step

A pre-build step can be added for each project to run NuGet Install. I don’t really like this as it is an unnecessary build step. This task is an “Update” task not a build task and the speed of my build is sacrosanct to me.

Manually with Batch File

After updating the local copy, the Developer can run a batch file manually to update packages.

for /r %cd% %%X in (*.csproj) do (nuget install %%~pX\packages.config -OutputDirectory packages)

This batch file command runs nuget install for every packages.config in a solution.

Automate the Batch File with Tortoise Hooks

Obviously an automated solution is preferred to adding a secondary step to the developer’s workflow. If your VCS client supports hooks such as TortoiseSVN client hooks  you can check-in the above batch file and get developers to hook it in to their VCS Update.

Configure NuGet to use shared packages repository

The true Holy Grail for people who don’t want to check-in packages is the ability to tell NuGet where packages live. It could then be configured to use a shared network drive to find the packages. This would be the same repository used by the build so by default it is always up to date. Unfortunately this is not yet a feature of NuGet. It is being discussed as a new feature, so if its something you are keen on go vote for it at

3 Replies to “NuGet Developer WorkFlow”

  1. This issue is the only reason I don’t use nuget with the team. I use it to get the dll(s) needed on my local system, but then I add them to the appropriate place in our svn:externals and change the reference and delete the nuget package.

  2. If you are willing to check-in DLL’s, it would be easier to check-in the packages to an external repository and then link it via SVN External. It would be less work and the whole team gets to use NuGet.

    1. You are right. I guess I need to engage brain on this one. I’ll give that a try.

      Yes, I check in dlls from 3rd parties into an Externals project rather than deploying them to every machine that needs to execute the app. The only exceptions are big suites like 3rd party controls that are integrated closely with Visual Studio. These I put in every GAC rather than using from the bin and referenced in externals.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s