Monthly Archives: March 2012

Configuring Hudson/Jenkins to parse MSBuild output

Posted by David Boike on March 14, 2012 4 comments

When I started with continuous integration, I used CruiseControl.NET, but the XML configuration quickly got to be really tedious.

It didn’t take me long to switch to Hudson CI.  It’s free, and it’s easily managed through an intuitive web interface. Not that I can’t grok XML configuration files; I’d just rather be spending my time building things instead of figuring out how to get them built.

For a primer on how to use Hudson CI for .NET projects, take a look at Getting Started With CI Using Hudson For Your .NET Projects by Bob Cravens, or Continuous Integration with Hudson and .NET

The only problem is Hudson is Java-based, so it’s not exactly plug-n-play when it comes to .NET, MSBuild, and Visual Studio. Particularly, when a build failed, I would have to scan through hundreds of lines looking for the cause of the error, which is difficult to do with CTRL-F when this line is completely normal:

Compile complete -- 0 errors, 0 warnings
 

What is needed is the Log Parser Plugin (link includes formatting rules), which allows you to define regular expressions that determine how to interpret the lines of content in the MSBuild output, so that warnings and errors can be called out in different colors the same way that Visual Studio does. This plugin can be installed through Hudson’s built-in plugin manager, but you have to configure it yourself.

Read more »

Loading external resources without killing ASP.NET

Posted by David Boike on March 12, 2012 2 comments

If you run an ASP.NET website with any non-trivial amount of traffic, the last thing you want to do is try to load an external resource with a web request. Even if you cache it, you’ve taken on that external source as a dependency to your system, which means that your website is only as reliable as the external source you depend on.

The primary strategy I’ve seen to cope with this is to request the data from the remote service on the first request from the web tier, cache it locally, and then have a background process periodically refresh that cache so that subsequent requests can use locally cached data.

Even with this background-updated cache, eventually the external resource will suffer some sort of issue. The data in the cache grows old and is invalidated, and then the web tier starts requesting the data again, except now, 100 different requests try to open 100 different connections to the remote service to get the exact same data, because either they all fail or none of them can complete quickly enough to store the cache item for the other threads to use. The Thread Pool fills up, and ASP.NET hangs its head and gives up.

The Solution

Let’s assume that we are talking about a current weather tease that is a small part of a very large page, and that all our current weather information for the end-user’s zip code comes to us from an external provider.

So how do we avoid this mess? We can do it quite handily with a little NServiceBus and jQuery.

Read more »