With NuGet finally bringing .NET dependency management into 21st century, an outstanding problem remaining for anyone who does custom builds of dependencies is that of storing them.
I like my dependencies resolved at build time, so that they don’t burden my source code repository. Which is fine, it’s easy to include custom steps to bring them in. However if I have to modify a dependency, which happens fairly often with open source, but remain in the NuGet world of managing it, I have a problem – I can’t upload this dependency to the public NuGet gallery (wouldn’t make sense even if I could).
Custom NuGet gallery to the rescue!
With NuGet gallery being an open-source we were able to setup a custom build that allows updating the packages. This allows us to keep the version number of the dependency while changing anything we need in it, which is a big deal when dealing with modern day dependency trees.
The workflow we use:
- Disable public gallery
- Temporarely enable  public gallery to bring in a dependecy
- Push it to the private gallery
- Modify the package if needed and update the private gallery
- Enjoy your unbroken dependency chain
I wonder how other people are doing this…
I think, therefore I spam. 
Why keep the version number unchanged? I realize the “true” version number is maintained by the open source group maintaining the project, but do you at least tag it in your private nuget repo to identify it as being modified? If not, how do you keep straight what has been modified privately and what hasn’t?
Hey Jim, several reasons we’ve had to keep the version number the same:
– Nuget packages list dependency’s version and may endup downloading and referencing older version
– Nuget’s way of updating the referenced version is to update the .config with binding redirects. We’ve had insurmountable difficulties with PostSharp failing to find the exact version referenced and breaking at compilation because it doesn’t look app’s config.
I consider packages patched in such a way a temporary throwaway and nobody on our small team cares if it was patched. Normally a clean build will re-download the package, but Nuget cache (http://nuget.codeplex.com/wikipage?title=Machine%20Level%20Cache%20Part%201) might need to be cleaned, in which case I notify the team.
Our build machine is spawned from a clean image (most of the builds, caveats apply) and it’s not an issue there either.