June 2008 - Posts

• CC.NET 1.4 Feature: Artifact Cleanup Publisher

  I didn't really have intentions of writing a mini-series dedicated to new features in CruiseControl.NET 1.4, but I keep finding good stuff, so I might as well keep writing (see here and here for previous posts). One of the key mechanisms of CC.NET is how it writes information to the XML build logs. The build logs can contain a ton of information, depending on how you've configured your build scripts. For example, the build logs for each of our builds contains the results from *at least* MSBuild, FxCop, and BitDiffer (of which I will post about very soon). Each of those tools produce a lot of data that gets merged into the build logs, thus creating build logs that are several MB in size. Obviously, that adds up very quickly so you have to take measures to periodically remove old build logs, all because you have thousands of them taking up several gigs of disk space. However, with the 1.4 release, CC.NET can take care of cleaning up old build logs automatically with the new Artifact Cleanup Publisher. For example, let's say you only want to keep the last 100 build logs. To do so, you simply add the following to your <publishers> section: <artifactcleanup cleanUpMethod="KeepLastXBuilds" cleanUpValue="100" /> Or what if you only want to keep the builds from the last 7 days? To do that looks like this: <artifactcleanup cleanUpMethod="DeleteBuildsOlderThanXDays" cleanUpValue="7" /> Yes, it really is that simple. The only caveat is that the <artifactcleanup> node must be defined *after* the <xmllogger> node in the <publishers> section, but that's all there is to it. Enjoy. Posted Jun 17 2008, 05:24 PM by Dave Donaldson

• CC.NET 1.4 Feature: Build Step Indicator

  I previously talked about how to specify multiple success exit codes with CC.NET 1.4, but there are some other enhancements with version 1.4 that people might also find useful. One of those is the new build step indicator, which provides visibility from the CC.NET web dashboard into what step of the build process is currently running. I actually stumbled on this feature by accident. After upgrading our build server to 1.4, I forced a build for one of our build scripts and after a few minutes clicked the "Refresh Status" button to see if its activity field changed from "Building" to "Sleeping", which means its done. However, I saw something like this instead: As you can see, not only is the "CS Web - Trunk" build in progress, but you also know that it's on the step where MSBuild is executing. And clicking "Refresh Status" again gave me this, showing me that it's moved onto the FxCop task:   It's not an earth-shattering feature, but comes in handy from time to time when you're sitting around waiting for a build to finish. At least now you have visibility into what step is currently executing. Posted Jun 13 2008, 07:11 AM by Dave Donaldson

• Specify Multiple Success Exit Codes with CruiseControl.NET 1.4

  One of the great things about using CruiseControl.NET is its ability to run any executable as part of a build process, which is done by utilizing the Executable Task wherever needed in a build script. As handy as this is, there is an issue in that up through version 1.3, if the exit code from running the executable was not zero, CC.NET would fail the build. In most cases, this was expected behavior and a non-issue; however, there are some executables where an exit code other than zero might not mean success, but might not mean failure either. A prime example is FxCop, specifically FxCop's command-line executable FxCopCmd.exe, which has several exit codes, some of which you might not want to consider fatal enough to break a build. Of course FxCopCmd.exe returns 0 for no errors, but it also returns 1 for analysis errors and 2 for rule exceptions, both of which are probably exit codes you can ignore. But even if you wanted to ignore exit codes other than 0 you couldn't because CC.NET didn't allow you to - until now with version 1.4. With the latest version, the Executable Task now includes a <successExitCodes> node that allows you to specify a list of exit codes that indicate success. So for the above FxCopCmd.exe exit codes, we can now do this: <successExitCodes>0,1,2</successExitCodes>. I upgraded our build server to 1.4 last week (using the latest build from ccnetlive) to take advantage of this new feature and all has been well. But if using one of those builds scares you, you'll be happy to know that yesterday the official release candidate was announced. And it's about time too because 1.3 was released almost a full year ago, so this update is welcome news. Enjoy. Posted Jun 12 2008, 05:19 AM by Dave Donaldson

• Save FxCop Messages to XML Report Only

  Or in other words, how to make FxCop *not* fail your builds... I've been spending a lot of time lately improving our build processes, part of which includes adding FxCop to our main trunk builds. I've added FxCop into the build process on just about every project I've worked on the last 4 years, but there's always been a problem: Every now and then an exception would occur in the build because FxCop tried to save the messages back into the .fxcop project file but couldn't, mainly because the .fxcop file is under source control and is read-only. I love FxCop, but this issue has always forced me to remove FxCop from the builds because as great as FxCop is, it should *never* be the cause of a broken build. It's never been a huge deal because I run FxCop manually all the time anyway, but it's something I've never been able to workaround. Until now. You see, all FxCop projects (those .fxcop files) have their own options, separate from the settings of FxCop itself (Project > Options). I've looked at those project options many times before but for some reason I never paid close enough attention to the Save Messages section, shown below with the defaults: What those options are saying is to save the messages into both the project file and the output file that contains the XML for the report. But that's not what we want. We only want the messages saved to the XML output file, not the project file: Like I said earlier, I don't know how I overlooked those particular checkboxes before, but setting them so that the messages are only saved to the XML report solved the problem. And now I'll never have to remove FxCop from a build process again. Happy days. Posted Jun 10 2008, 11:25 PM by Dave Donaldson

• Two Essential Tools for Vista

  By all accounts, I'm the only person on Earth who has not experienced any real issues with Windows Vista. It's a shame really because Vista's overall experience is so much better than any previous Windows operating system. Yet not a day goes by without some new report of how big a failure Vista has been. But for all my good luck with Vista, there are a couple things that surprisingly don't perform as you'd expect from an improved Windows operating system: copying files and Windows Explorer. When it comes to copying files in Vista, I've yet to see a dialog box that tells me it's going to take 6,209 days to copy 2MB worth of files, but it's not always consistent either. Sometimes it's really fast and other times it's definitely slower. It got a little better with SP1, but still not really what it should be. As for Windows Explorer, there are times it just crashes. It's not all that often, but it's noticeable enough for me to bring it up. Granted, it always recovers nicely, but we should be past the days of Windows Explorer crashing, for any reason. In addition to the crashes, every great now and then it takes forever to respond when I click on a different folder. I mean, it's just an updated version of File Manager from Widows 3.1. The last thing I'd expect to have problems with in a Windows operating system is Windows Explorer. With that being said, I recently came across two tools that alleviate both of these problems: TeraCopy and Xplorer2. TeraCopy I came across TeraCopy in a blog post by Jon Galloway. I don't want to completely steal Jon's content, so I'll just cherry-pick some choice phrases: "shell integration into Explorer is really smooth", "that nice Pause button", "should my VPN drop or the copy fail for any other reason, that button changes to Resume and I can continue the copy from where it left off". And even though Jon has a couple screenshots of TeraCopy, I'll include one of my own: So yes, TeraCopy's features are nice, but the most important thing is that it copies files fast. It performs like Vista should perform, and is definitely a must have tool. Xplorer2 I found out about Xplorer2 in a tweet from Rick Strahl. Curious, I had to check it out and am definitely glad I did. It's got some nice features such as tabbed windows and a dual-pane viewer, but its best features are its performance and stability. Definitely an improvement over Windows Explorer and something to strongly consider. One thing to know if you're using Xplorer2 and TortoiseSVN: if you want the icon overlays of TortoiseSVN to appear in Xplorer2, be sure to uncheck "Show overlays only in explorer" in your TortoiseSVN settings. That tripped me up for a few minutes until I realized that I had that setting turned on. After unchecking it I was good to go. Enjoy. Posted Jun 07 2008, 12:43 AM by Dave Donaldson