One of my goals in spinning up a software development team at Foxguard has been to have a development environment ready to go before the first person comes through the door.  That means a vague skeleton of the application we are developing as well as the apparatus of building, deploying, and testing that application.  Since anything worth doing is worth doing right we’re approaching the latter problem with a Continuous Deployment solution in mind.  That means that every time we commit code it is picked up by a automated script, built, tested, and published — ready to begin evaluation through some as-yet-to-be-determined test suite.

The first part of this is fairly easy.  Jenkins is a great tool and there is no shortage of tutorials out there on how to make it play nicely with GitHub, MSBuild, or any other technologies you might be using.

Deployment, though, is a bit of an more difficult nut to crack.

MSBuild can be configured to spit out some deployment packages with the addition of a few arguments.  Here’s my Jenkins configuration by way of example:

A project built like this will get you a bunch of deployment configuration files and batch files dumped into “\workspace\[Project]\obj\Release\Package\”.  Among them will be a file named [ProjectName].SetParameters.xml which has database connection information that you’re going to want to change and a nigh impenetrable command file named [ProjectName].deploy.cmd.

This is where I ran into trouble.  Running the cmd file gave me errors which looked a lot like this:

C:\Program Files (x86)\Jenkins\jobs\My Site\workspace>
MySite\obj\Release\Package\MySite.deploy.cmd /y 
/m:https://10.0.51.120:8172/msdeploy.axd /u:myuser /p:MyPassword 
/a:basic -AllowUntrusted "-setParam:name='IIS Web Application Name',value='MySite'"

\Jenkins\jobs\My was unexpected at this time.

A lot of fruitless Googling followed this before I started to wonder if maybe, just maybe, Jenkins (or maybe the command file itself) might be having problems with the expanded directory naming convention that Microsoft ported over from the Unix world back in the 1990s.  So,  I added a line to move all of the deployment files into a much less challenging looking directory: “C:\Deploy\” and gave the build another kick.

And it worked.  Because, of course it worked.

In any case, fellow traveler, should you find yourself on this page because Google brought you here, I hope you can benefit from my frustration. Of course, with any luck, this issue will be fixed long before anyone bothers to read this.