I wanted to add continuous code coverage to my little extension library project, and so realised i would need to run one of nCover, dotCover or openCover from the command line on my build server. This calls for a task based build automation library!

Because I’m started to learn more about this nodejs thing as a .Net developer, I figured I should give one of the build automation projects from there a go, even though my project is a .Net library and I dont need node (even if it is a PCL).

A Few Hurdles

So the first major problem is node itself. not a current dependancy from any of the project, so that needed to be installed. Not a big deal, i did have to hack around with powershell to set up node so that npm was recognised, but thats a once off per machine. Then I had to add a package.json file, that was that.

Next up was gulp, again, not too bad except that I did have issues getting gulp recognised as a command, but a few powershell restarts and some new PATH variables and that was fine too.

Now to get gulp to build and run my tests. Luckily there is a gulp-msbuild task that I could install, which works without much trouble. Unfortunately, there was no gulp-mstest. after much trial and error, I found and used the node package mstest, and jumped some extra hoops to do a manual gulp task for that. I notice that there is a grunt-mstest available, and a gulp-nunit, so not too big a deal for others that might be following a similar path.

I even managed to get a AssemblyInfo rewritter build step as well, which was a nice, but unnecessary bonus at this stage.

About now, after several hours mucking about, I realised that I had achieved the following:

• Introduced an unnecessary dependancy on nodeJS
• Added new node-module dependancies to the setup of my build tasks that need downloading
• Require you to spin up an entire node environment, just to shell out to command line applications to build and test my .Net project.

I haven’t even got to code coverage and already feel I’m breaking ground, and will need to build my own node libraries for gulp to run my tests and code coverage. At this point I also realise since ive been doing the whole thing in powershell, I should just install psake and be done with it.

Conclusion

If you’ve got a web application in .Net and you will need a pipeline for less/sass/typescript/coffeescript/javascript , gulp is a nice way to go, and can even do the build, run the test, package to a zip and/or deploy to your environments for you. But if all you have is a .Net library with no web requirements whatsoever, I recommend psake, with a little chocolatey for environment dependancies thrown in.

For your interest

You can check out the changes in the following Commit (I’m pretty sure it’s going to become psake pretty soon.)