CI Builds and Package Update issues

Topics: General
Aug 31, 2012 at 2:51 PM
Edited Aug 31, 2012 at 2:53 PM
Okay, here's my situation.
  • I have a source control setup where we have multiple repositories, with some code in one repo (repo 'A') needing to reference dlls built out of the other repo (repo 'Common').
  • I'm trying to use nuget to help with this
  • I have repo 'Common' creating nuget packages with the CI build and publishing the packages to an internal repository
  • Those packages are given version numbers with the build number in the 4th digit, e.g. 1.0.0.201208301
I have a project in repo 'A' that uses a package published out of repo 'Common'.  When a developer references said package, it adds an assembly reference to their project with a hintpath something like "..\packages\MyComponent_1.0.0.201208301\lib\net40\MyComponent.dll".  Package restore is used, so packages are automatically downloaded and all is well.
Until the next build of 'Common'.
When package 1.0.0.201208302 out of Common is published, I can tell developers 'OK, just update your packages and it'll re-point your references'.  However, my build machine is a bit of a problem.  I want the next build of 'repo A' to reference the latest version of the 'Common' nuget packages.  In order to do that, I need to run nuget update as part of the build.  OK, fine. However, nuget update modifies the packages.config file and the csproj file to point to the new package version and hintpath for the references.  With TFS that's kind of a problem, as I need to check out those files to make them writable.  And even then, what do I do then?  Check those files back in?
The only option I think I'm left with at this point is to leave the build number off of the package versions.  This is the easiest for my CI builds, but is less than ideal for the developers.  To get the latest package version they can't just use the update feature of nuget itself.  They have to delete their local packages folder and let package restore get the latest rev.
Are there alternatives that I've missed here?  What I think I'd really like is to be able to put that 4th build digit back on the package versions, and have things setup to work like this:
  • The version in the packages.config file leaves off the 4th build digit.
  • The package installation location (and subsequent hint paths) leave off that 4th build digit as well.
  • Package Update picks up when a package has been published with a new build number, and updates over top the existing local package
  • Package Restore always grabs the newest package with the same major, minor, and patch version, going with the one with the highest build number.
Thoughts on adding a couple options, perhaps in nuget.config that would make Nuget function in this manner?
Aug 31, 2012 at 3:19 PM

Rather than do a TFS check out to make the files writable, why not make them writable yourself (e.g. using the attrib command)?

Aug 31, 2012 at 3:41 PM
quintessential5 wrote:

Rather than do a TFS check out to make the files writable, why not make them writable yourself (e.g. using the attrib command)?

Sure, that's an option.  

I'm still looking for alternatives that don't involve changing the packages.config and csproj files as a part of the build, though.  Mainly, because I'd like to use incremental builds in TFS as well.

Also, thinking a down the road (6 months to a year) I'd like to have the option of purging old versions of these nuget packages.  If there are stable bits of code that still explicitly point to a six-month-old version of a nuget package it kind of prevents me from archiving them without doing a massive nuget update first.

Sep 20, 2012 at 10:34 AM
vermeeca wrote:
However, nuget update modifies the packages.config file and the csproj file to point to the new package version and hintpath for the references.  With TFS that's kind of a problem, as I need to check out those files to make them writable.  And even then, what do I do then?  Check those files back in?

Absolutely not... in fact the only time you should commit new versions of packages.config and .csproj to version control is when you move to the next major or minor version.  Leave the versions at 1.0.0.0 in those files, and anyone who runs update (with the -Safe flag) will get 1.0.0.6123176,  1.0.0.6123177, 1.0.0.6123178 and so on.



 

Sep 20, 2012 at 10:56 AM
Edited Sep 20, 2012 at 10:59 AM
Absolutely not... in fact the only time you should commit new versions of packages.config and .csproj to version control is when you move to the next major or minor version.  Leave the versions at 1.0.0.0 in those files, and anyone who runs update (with the -Safe flag) will get 1.0.0.6123176,  1.0.0.6123177, 1.0.0.6123178 and so on.

 

Agreed, and if this were for a small project I'd be fine with that.  However, I don't believe that's tenable in my case.  Nuget's default behavior is to stick all four digits of the version number into packages.config, and I can't really tell all 60 or so devs in my org to manually go back in and edit packages.config every time they add or update a reference.

For now, I'm just leaving that fourth build digit off of my package version numbers until I can get the behavior I outlined in the first post, or another sustainable alternative can be found.  

Also, I'd really like feedback as to whether the features I outlined above would be a good addition to nuget.  If so, I can start working on a pull request.