Bruce, I wonder if "Some Company" is the same "large" insurance company I am currently consulting to right now. :-)
Wow, there's a lot going on with your message.
Consuming of NuGet packages is not part of NuGetter - that is a general build/compile requirement. NuGetter's purpose is strictly the creation of packages. However, to create packages, you very likely have to consume them. So, as an initial
answer to this, I created the build templates that are available through my blog (http://marknic.net). (They are NOT NuGetter specific. The templates are modifications of the standard TFS default build templates.)
Those templates allow you to dynamically pull down NuGet packages as part of the build process rather than including them in source control. The second template that I included does the same download as the first plus dynamically updates the packages
with the latest (insert your definition of the latest here) packages. To do all of this, your projects ("**proj) files must be updated on the fly. All of this is managed using the NuGet application so the capability it provides is the functionality
you get here.
Note: you can still use these templates even if you include NuGet packages in source control. The process will skip over things that are already there.
To control the meaning of "latest" take a look at the NuGet documentation for more specific definitions to what I describe below. There are a couple command line parms as part of "update" that let you dictate what kind of update process will
- No additional parameters: the latest published packages will be used
- "-safe": the latest published, non-breaking change release will be used
- "-prerelease": the latest non-published but available packages will be used
- "-safe -prerelease" the latest not yet published/non-breaking change packages will be used
You can include these additional parameters in the templates that I created. Hopefully the combinations above will satisfy your needs.
<myOpinion>One thing I feel I should add. I completely understand why you would want to do this dynamic update to the latest version from the point of view of testing but I really don't see it as a CI philosophy since you could be changing application
code and dependency assemblies at the same time (during the build) therefore creating situations where failures in the tests could be very difficult to use as indicators of the real problem. Your code may not even compile. Also, more importantly, it
could mean that the application you have in production does not match the code you have in source control.</myOpinion>
As for using this in NuGetter (or TfsVersioning for that matter) I still need to create updated templates for them. I've started in NuGetter but haven't finished yet. As with any project, time/resources is the biggest limiter. One of my
biggest wishes for the new year is a more modular TFS build workflow system where you can include external template "subroutines" rather than creating monolithic templates.
I tried to make the restore/update section in the templates as tight as possible so you could copy/paste them into existing templates.
Lastly, NuGetter relies upon the solution and configuration to determine what it packages. So, I don't think we have parity with your MSBuild script. I realize that I don't have a full understanding of your environment but I am trying
to figure out the benefit of doing this (other than the obvious getting it all done at once). I can see very real versioning issues with this approach. Also, questions like: is it really necessary to always build all of that code all
of the time? If there's a framework that the various target packages have in common, then maybe that should be a separate package and a dependency of the main packages.
Anyway, hopefully this answers some of your questions, Happy Holidays and Festivus for the Rest of Us!