How to correctly set up a proper fully automated release workflow?

Topics: General
Jan 11, 2013 at 9:23 PM

Hi,

I have a somewhat complex question. I'll give a description with my thoughts in detail below, but the question boils down to:

How do I set up my solution and NuSpecs 'the proper way' to do build and package up several projects with multiple framework target versions in a single, fully automated build run?

What I want to do is, basically, have a solution that is able to do everything that is required for a full release on it's own, not requiring any manual steps except perhaps for triggering it. I want everyone cloning the repo be able to do a full release-ready build, except for automated pushing. Actually I'm pretty deep in MsBuild, so automating almost everything is not a real problem, but I have several problems with certain details:

First of all, I have a library that should be published as a NuGet package. This library should be build for several .NET framework versions. There are multiple ways to achieve this, and I don't know what's the one 'most compatible' with NuGet packaging.

What I want to avoid is the need of copying around files a lot (that needs a lot of cleanup logic - running a 'Clean' should end up in the same state as a clean checkout, except perhaps for some additional empty folders), and re-implementing stuff that's already there (like token replacement in a NuSpec file).

My options I thought of are:

  1. Multiple project files (MyProject.Net20.csproj; MyProject.Net35.csproj; MyProject.Net40.csproj). While probably being the easiest to set up solution this requires a lot of manual work maintaining this library (each file must be added to several projects etc.). I consider this ugly and this would be the last resort solution.
  2. One project file with multiple configurations. This makes it more difficult to take care that all different configurations are built when building a full release, but it is doable with some MsBuild magic and special project files / targets. But this left me in a state where packaging makes problems and I can't automatically package up all files from different configurations in a single NuGet package.
  3. One project file just with the two configurations Debug and Release, but taking target framework version and output paths from a special project file. That also works, but leaves me with the same problems as above.

The packaging problems left me with a package that contained only the files for the default target framework, but not for the others. I already layed out the different binaries in bin\Release\netXX\ folders, but they were not recognized. When I added them in the nuspec, it threw errors that the original files were already included in the package and it can't insert them again.

The other problem would be, that I can only package up Release builds, because it does not seem to be possible to use bin\$(Configuration)\netXX\ as the path to include the binaries from.

Working with a nuspec not updated by a project (or two, one for release and one for debug) would require me to re-implement the token replacement from the assembly and is a no-no. And actually it would make sense to also provide internal packages from debug configuration together with the pdb for detailed exception informations.

 

After all, I don't see how this could be easily achieved without a lot of trickery on either side (VS solution/project setup and/or NuGet package modification), but I think automating this should be an easy thing to do.

Any ideas / thoughts / suggestions on this?

Regards,

   Sebastian