Experience of using NuGet to implement nightly build consuming

Feb 21, 2012 at 7:28 PM

Hi NuGet team,

I’d like to provide some feedback on my recent work with NuGet.

­Due to my team’s plan, recently I’m adjusting our test project to see if we can entirely rely on NuGet restore mechanism to consume the nightly builds (product binaries). The idea of using nuget without committing packages to source control is exciting and it works fairly good if the packages is not updated frequently, say, once every couple months. However consuming a nightly builds is another story. Here’s some feedback about what makes the experience bad and ultimately makes me give up the idea for now.

The key is that version is updated nightly. So that the path to the binaries in package folder changes nightly, therefore maintain the references in project file becomes painful. I tried two strategy to solve it:

Using ExlucdeVersion option

Ideally ExcludeVersion option create version irrelevant path and actually it works. However it really doesn’t work well with restore. When two nuget packages depends on a third packages, both of them think each other is depending on the third part so skipping the installation. As result the third package is never updated.

Using property to control the path

It’s a common strategy. Well, it fails because it lacks an easy way to retrieve the version of a given nuget package. You can do through command line, however it’s not convenient to call from MSBuild file. I tried custom MSBuild task, but it can’t be executed without a target. I tried use a file to persist the number, while the updating process is too complicate so not worth to implement for such a small engineering problem.


Beside above issues, some additional problems also bring difficulties to enginerring:

Update package from a local file share source

There is additionally another “bug”, since the nuget packages are nightly build. Commonly we will not push them to the server, instead we persist them on the file share. I tied use Nuget Update command to update from a file share source. However it doesn’t work. It simply doesn’t compare the nuget in file share to the ones in your package folder.

Packages.config requires version

Without the version attribute, a package in the configure file will be ignored. It’s not intuitive and there is no error/warning message. From my perspective, it makes more sense to allow this attribute to be missing so as implicitly tells nuget to always install the latest version.


Don’t get me wrong, NuGet is great. Just the nightly build consuming scenario is not ready yet. I hope my experience can provide some value in the future releases.

Should you have any question please feel free let know. If you have any idea that something else I can do to implement the scenario, it would be great. Please ping me whenever you can.