For the last while I’ve been trying to setup an automated build script + CI server for our software. Because of how the repository is laid out as well as limitations of the software available, it has become quite an adventure.

The ‘build script’ itself is effectively a batch file. The idea is that developers may want to perform a full rebuild manually, outside of a CI server. Originally, we were going to use TeamCity because it has built-in .NET support, being able to just build a solution directly. This did have several problems though. The main one being that the free version is limited to 20 Build configurations. Not an unreasonable limitation, but it is problematic since we need to workaround it. it was partially avoided by adding a single job per branch,but each branch would require a build configuration and we would eventually hit 20 supported branches. The workaround was to have only one build configuration that pulled down the entire repository and have build steps build each branch- but hacks are probably the last thing we want. Also, it could probably be argued that trying to workaround this sort of license limitation in otherwise commercial software is kind of unethical. There is unlikely to be a good justification to pay the 2K for the required license to use- and if we can find a better alternative, that will be preferred. That is where Jenkins came in.

Jenkins is a continuous integration server based on Hudson. It is originally designed for Java and has great Java support, but if we want to build .NET stuff, we need to effectively do it manually. Of course, at this point I’ve already constructed an elaborate build script that we can launch directly with a few parameters, so I went ahead and did that.

I was hoping for but not expecting immediate success. What ended up happening was a full day of trying to figure it out. My first issue was that one of the programs failed to find a referenced assembly, because it couldn’t find “C:\Program Files %20×86%21\Jenkins\Job…” Which is sort of obvious given that the path has had parentheses escaped. I researched the issue and discovered that this was actually a limitation of MSBuild, and certain tasks were apparently busted- like a flustered warden, it just couldn’t deal with escapes. The reason I had not encountered this with TeamCity as it turns out was simply because I had installed to C:\TeamCity (the default location). In hindsight I wondered why it was installing to that location, but now it seems that it did so because of .NET limitations (TeamCity being .NET centric in some regard it makes sense they would avoid MSBuild-related issues).

Excellent! I found the problem. So I uninstalled Jenkins, rebooted, reinstalled Jenkins to C:\Jenkins, recreated the Job… and was met with disappointment. This time, the build failed with a curious error from NotifyPropertyWeaver.dll. we have this DLL set as part of a post-build step for ome of our libraries- coincidentally the same one that was having problems, as previously it was this dll that claimed it couldn’t be found.

I was running Visual Studio 2015 CTP6, so I thought, “ah, it must be a issue with the Roslyn compiler, and NotifyPropertyWeaver.dll cannot understand the new compile format! Of course! Already patting myself on the back, I began the grueling effort of uninstalling Visual Studio CTP6 and installing Visual Studio 2013. It kind of makes me feel bad since as an MVP I feel obligated to at least try out new Language features and try to keep on top of such technologies, but the choice had to be made.

After finally getting VS 2013 installed, I attempted to run the build again- and I was greeted with the same error message. Well so much for that theory, it seems. And I was so sure it was the cause!

I was kind of out of ideas at this point, so I started doing some experiments. I found that I couldn’t build it manually, either. I was able to build the same build script checked out to my user folder without issue. Then I tried running as administrator and then building in my user folder- I found I was meeting the same error.

Based on this I changed the Security ACL on the C:\Jenkins folder to include full control for all authenticated users- and Jenkins was able to compile all the .NET programs successfully. (Since I hadn’t installed the JDK it hit a wall with the Java applications we have in our codebase which was to be expected).

It was a simultaneously interesting and exciting adventure. It is disappointing since I spent the whole day trying to figure it out when my intention was to sort out how build artifacts were created.