Mike Dellanoce's Blog

Zero-friction Javascript Minification with RequireJS and Express

2011-12-10T15:45:00.000-05:00

Most software development efforts involve multiple source code files, and Javascript-heavy web applications are no exception. However, if you want your application to load fast, then you need to combine and minify all those Javascript files somehow. RequireJS is a library that can help with this process by allowing you to define javascript modules and the dependencies between them. In "development mode", RequireJS will download modules individually as they are needed. When all of your scripts are shiny and bug-free you can run the optimization tool which will analyze the module dependencies and create a single, minified Javascript file.

The optimization tool is usually run as part of a build process before deploying the application, but if your application runs on Node.js you can eliminate this extra step. Since the optimization tool is itself a Node.js script, it can be invoked directly from the application's start-up code. Here is what this might look like with the fantastic Express web framework:

In development mode, the application will serve the non-optimized Javascript files from the public folder. In production mode, the RequireJS optimizer will combine and minify the Javascript files and serve the optimized files from the public_build folder. Any other files in the public folder (such as images and stylesheets) will also be copied to the public_build folder, so you don't need to clutter your source code repository with generated files.

Commit early, commit often

2011-12-04T08:48:00.000-05:00

Hidden deep inside TortoiseSVN is a reporting tool that can give you statistics about commits to your repository. I ran this report at my day job several times over the years and the output has always been a quiet source of pride for me. I decided to publish the report here since I'm moving on to a new project. If nothing else, it serves as a reminder to myself of what I spent in the last four years doing:

This is the commit history for the entire four years of the project up to the date when this post was published (names have been removed to protect the innocent). I account for about 18% of the total commits to the repository. One of my teammates (who incidentally owns the third highest bar in the graph) claimed that I average 7.5 commits per hour assuming a 40 hour work week (ha). I think his math might be a little off since I calculated a significantly less impressive 5 commits per day when I ran the numbers... although maybe his numbers are a little closer if you exclude the year I served in management.

Hold on a second...

This can't be fair, can it? I've been on the team longer than anyone else at this point, so of course I've amassed more commits. Well, let's look at the commit history for one month during which the team membership was relatively stable:

Me again, and by a wider margin, too.

A lot of my teammates were shocked as these graphs made their way around the team, but there are benefits to working at this pace:

You are less likely to break something with a lot of small commits than you are with a few huge ones,
Your teammates see your code sooner, so you get feedback sooner and reduce the risk of merge conflicts,
Customers get features and bug fixes sooner (as long as other organizational factors don't stand in the way),
And plenty of other reasons smarter people have already enumerated.

For me, writing software is all about momentum. I am more stressed out at the end of the day if I don't commit a whole bunch of code.

Happy committing!

Octophile: Social media widgets for GitHub

2011-11-15T06:54:00.001-05:00

Last week I put one of those Twitter follow buttons on my blog. It was cool, but it looked a little lonely all by itself. It occurred to me that other developers can follow me on GitHub too, so I started looking for a similar button for GitHub. Much to my surprise, I was not able to find one. Luckily, GitHub has a pretty awesome API, so I decided to try to make a follow button for GitHub myself. I cobbled together a small sinatra application, pushed it to heroku, and octophile.com was born!

You can see the GitHub follow button in action off to the right (if you are reading this on my website and not a RSS reader). If you find this button useful, or would like to see some other widgets like this, I'd love to hear your feedback.

Happy coding!

Update 11/19/2011:
I have since found that something like this does already exist: github anywhere.

Easy vagrant setup on windows with chocolatey

2011-10-13T21:37:00.000-04:00

Setting up vagrant on windows is well-documented and, overall, pretty easy. However, it is a little more complicated than just:

gem install vagrant

Luckily, us Windows developers recently got chocolatey. I just put together a few packages that makes vagrant setup on Windows a snap. To try it out just follow the chocolatey installation instructions. Then open a command prompt and run:

cinst vagrant

This command will download and install JRuby, VirtualBox, PuTTY, and the vagrant gem. It will also automatically set the registry keys for putty so that once you set up a box with vagrant you can SSH into it with:

putty -load vagrant

At this point the package comes with the old "works on my machine" stamp.

Check out the code on github or report an issue.

Update 11/10/2011:
More recent versions of the package will not modify the putty registry with the vagrant profile. Instead I recommend installing vagrant-putty.

Enabling Pound proxy support for the HTTP methods PUT and DELETE

2011-09-22T09:56:00.000-04:00

I'm not sure how many people out there are using Pound as a reverse proxy, but if you have it sitting in front of a ReSTful web service you may run into some issues with HTTP methods other than GET, POST, and HEAD. By default Pound only supports GET, POST, and HEAD. Pound will return an HTTP status code of 501 (not implemented) if it encounters a different method, such as PUT or DELETE.

Resolving this issue is easy. Each ListenHTTP or ListenHTTPS section in your pound configuration may contain the xHTTP setting. The default value for this setting is 0 (GET, POST, and HEAD). Setting the value to 1 adds support for PUT and DELETE. So putting it all together:

ListenHTTP
   # ... some settings
   xHTTP 1 #Support GET, POST, HEAD, PUT, and DELETE
   # ... some more settings
End

Happy proxying!

HTML Basics: Labels and inputs

2011-08-29T07:19:00.000-04:00

I stumbled across some code the other day that made me smile. Here is essentially what was going on:

<input id="checkbox" type="checkbox" />

<label id="label" for="checkbox">My Label</label>



<script type="text/javascript">

$('#label').click(function() {

   var checkbox = $('#checkbox');

   checkbox.attr('checked', !checkbox.is(':checked'));

});

</script>

Naturally, this bit of javascript will toggle the checkbox's checked state whenever the label is clicked. There is nothing functionally wrong with this approach, except that it is wasted effort. Every browser I have ever worked with will do this automatically without any javascript. Simply associate a label with a checkbox (or radio button) and clicking the label will toggle the checkbox's checked state:

<input id="checkbox" type="checkbox" />

<label id="label" for="checkbox">My Label</label>

Go ahead, click me

Testing MySQL queries with NUnit

2011-03-27T09:35:00.000-04:00

Even the most adamant unit-testing purist will admit that database queries need to be tested. If possible, these tests should run against the same database engine that will be used in production.

With a SQL Server database, testing queries is fairly easy, since most Visual Studio installations will include SQL Server Express. Just create the database in a SetupFixture, connect with Windows Authentication, and you're all set. MySQL presents a few more challenges, however. First, it needs to be installed. Second, the tests need the correct credentials to connect to the installed MySQL instance.

One simple way to handle this is to set up a central MySQL instance for testing only. However, this means team members must be on the network to run the tests. There is also the issue of multiple team members running the tests at the same time causing unexpected failures in each other's test runs, or worse, causing unexpected failures in an automated build.

A better alternative is to keep the MySQL binaries in version control with a known configuration that can be used in test runs. The binary distribution of MySQL is fairly large; however, with the right command line arguments, we only need two files: bin\mysqld-nt.exe and share\english\errmsg.sys (or whichever language you want to use). Include both of these as content files in a test project and set the build action to "Copy If Newer". In a SetupFixture, start MySQL with some code like this in the setup method:

var process = new Process();
var arguments = new[]
{
    "--standalone",
    "--console",
    "--basedir=.",
    "--language=.",
    "--datadir=.",
    "--skip-grant-tables",
    "--skip-networking",
    "--enable-named-pipe"
};

process.StartInfo.FileName = "mysqld-nt.exe";
process.StartInfo.Arguments = string.Join(" ", arguments);
process.StartInfo.UseShellExecute = false;
process.StartInfo.CreateNoWindow = true;

process.Start();

The first two arguments (--standalone and --console) tell MySQL to run as a standalone instance and to keep the console window open (i.e. do not run as a service). The next three arguments (--basedir=., --language=. and --datadir=.) tell MySQL to run from the current directory, load language files (errmsg.sys) from the current directory, and write data files to the current directory. The --skip-grant-tables argument disables security so that the tests do not need to worry about providing credentials when connecting. The final two arguments (--skip-networking and --enable-named-pipe) tell MySQL not to listen for TCP connections and instead allow named pipe connections. This prevents our standalone MySQL instance from interfering with any other MySQL installations on the machine.

Once the instance has started, we can connect with a connection string like this: Data Source=localhost;Protocol=pipe;. Finally, kill the MySQL process in the SetupFixture teardown method.

On my team, we have rolled this functionality (and a few other goodies) into a NUnit addin, but that's a story for another blog post.

Happy testing!

NServiceBus assembly scanning: avoiding unintended consequences

2011-02-10T08:56:00.000-05:00

The default startup behavior for a NServiceBus endpoint is to scan all assemblies in the deployment directory for any types it might be interested in, for example, message modules and message handlers. This is really handy, but occasionally it can lead to unintended consequences. Fortunately, the With method has a few overloads and one of them takes a list of assemblies to scan. If you want to prevent loading types from any stray assembly that might make it into your deployment directory, change your initialization code to look like this:

var assemblies = GetType().Assembly
   .GetReferencedAssemblies()
   .Select(n => Assembly.Load(n))
   .ToList();
assemblies.Add(GetType().Assembly);
NServiceBus.Configure.With(assemblies);

This restricts the assembly scanning process to only the assemblies that your endpoint explicitly references. We can extract this code to an extension method so we can use it in other endpoints:

public static IEnumerable<Assembly> ReferencedAssemblies(this Type type)
{
   var assemblies = type.Assembly
      .GetReferencedAssemblies()
      .Select(n => Assembly.Load(n))
      .ToList();
   assemblies.Add(GetType().Assembly);
   return assemblies;
}

Now our endpoint initialization looks like this:

NServiceBus.Configure.With(GetType()
   .ReferencedAssemblies());

Assert.DoesNotThrow... why does it exist?

2010-12-21T06:54:00.001-05:00

Take a look at this test:

[Test]
public void TestSomething()
{
   Assert.DoesNotThrow(MethodUnderTest);
}

It seems to me that it is functionally equivalent to this test:

[Test]
public void TestSomething()
{
    MethodUnderTest();
}

In other words, Assert.DoesNotThrow is the same as writing a test with no assertion. Is it really enough that the code runs without throwing an exception? Presumably the method under test is doing something, so shouldn't you verify those results with a stronger assertion?

AsyncController and custom action invokers

2010-12-07T07:00:00.000-05:00

If you are trying to get AsyncControllers to work, you might run into this gem when you try to test your controller:

If this happens to you, a custom action invoker is likely to be the culprit. In my case, I was using Castle Windsor, and I had extended ControllerActionInvoker to provide dependency injection to my action filters. My action invoker looked something like this:

And this is how I had registered the action invoker with Windsor (this assumes you are using a controller factory that is aware of Windsor):

All I had to change to fix the problem was to make my custom action invoker inherit AsyncControllerActionInvoker instead:

AsyncControllerActionInvoker implements IAsyncActionInvoker and adds a few new methods. Depending on what you are trying to accomplish with your custom invoker, you may need to override a few of these new methods as well.

Interestingly enough, I did not have to change how the invoker was registered with Windsor.

Using AsyncController with NServiceBus

2010-12-06T07:18:00.000-05:00

With NServiceBus sometimes you do not want to allow a web request to complete until you have received some response from your message handler. For example, suppose you have defined the following message handler that returns a response code on success:

public class TestMessageHandler :
    IHandleMessages<TestMessage>
{
    public IBus Bus { get; set; }

    public void Handle(TestMessage message)
    {
        //Do something interesting...
        Bus.Return(0);
    }
}

This is a perfect scenario for using the asynchronous page API. It allows you to execute a potentially long-running operation on a separate thread outside of the IIS thread pool. While this thread is executing, the original request thread is returned to the thread pool. As a result, the asynchronous page API is great for I/O bound operations, since you keep threads in the thread pool ready to service requests and the new thread spends most of its time blocked on I/O. NServiceBus supports the asynchronous page API out of the box:

Bus.Send(new TestMessage()).RegisterWebCallback(callback, state);

Unfortunately, RegisterWebCallback does not work with ASP.NET MVC. If you are using ASP.NET MVC, you can use AsyncController, which was introduced in ASP.NET MVC 2. The following code illustrates how you might use AsyncController to wait for a response the message handler:

public class TestController : AsyncController
{
    private IBus bus;

    public TestController(IBus bus)
    {
        this.bus = bus;
    }

    public void IndexAsync()
    {
        AsyncManager.OutstandingOperations.Increment();

        bus.Send(new TestMessage()).Register(Callback);
    }
    public ActionResult IndexCompleted()
    {
        return View();
    }
    
    private void Callback(int responseCode)
    {
        AsyncManager.OutstandingOperations.Decrement();
    }
}

As you can see, the AsyncController API is a little awkward (though it is an improvement over the asynchronous page API, in my opinion), but it is a small price to pay for scalability.

Ctrl-C and the NServiceBus generic host

2010-08-14T15:07:00.002-04:00

Ten posts and almost a whole year later, my very first post about NServiceBus is still by far my most popular. So here is some more NServiceBus-y goodness.

Last week a coworker came to me asking for help with a self-hosted NServiceBus application. He had a small console application set up to test NServiceBus and it worked beautifully in all but one case. When he killed the application with Ctrl-C, the message being processed was always lost. At first I thought maybe the application was not using a transactional endpoint, but it was configured to do so. I did not see the same behavior with the generic host running in console mode, so I figured the generic host was handling Ctrl-C somehow. A quick search turned up the CancelKeyPress event. I opened up the generic host in reflector, and, on a hunch, navigated to the TopShelf.Internal.Hosts namespace (the generic host internalizes another excellent open source project called TopShelf). Sure enough, the TopShelf console host handles the CancelKeyPress event, and ultimately allows all of the worker threads in NServiceBus to finish handling messages before shutting down.

One question this brought up is what happens if someone pulls the plug on my machine after a message has been received, but before it has been processed? My impression was that a transactional endpoint would take care of this, but now I'm not so sure.

Over-testing: the data-driven edition

2010-07-27T20:32:00.001-04:00

Learning to test at the right level of abstraction is tough. A common mistake involves the abuse of data-driven testing tools. Data-driven testing tools, like TestCase in NUnit, are convenient and powerful. You can write a lot of tests really fast, but if you're not careful, you can end up repeating yourself.

For example, suppose we define the following (woefully oversimplified) utility function to test if a string is a valid email address:

public static bool IsValidEmail(string email)
{
    return Regex.IsMatch(email, @"\w+@\w+\.com");
}

The test suite for this function should be complete. A data-driven approach works really well here:

[TestCase("a@test.com")]
[TestCase("1@test.com")]
//... lots more
public void TestValidEmail(string email)
{
    Assert.That(IsValidEmail(email));
}
[TestCase(null)]
[TestCase("not an email address")]
//... and so on
public void TestInvalidEmail(string email)
{
    Assert.That(IsValidEmail(email), Is.False);
}

Now, suppose we use this method in some application logic:

public void SendConfirmation(string message, string email)
{
    if (!IsValidEmail(email))
    {
        throw new ArgumentException("email");
    }
    SendEmail(message, email);
}

Awesome, let's test this bad boy... er, I mean here's the test we wrote before writing the method:

[TestCase("a@test.com")]
[TestCase("1@test.com")]
//... lots more
public void TestSendEmailIfValid(string email)
{
    SendConfirmation("test", email);
    //Assert sends email...
}
[TestCase(null)]
[TestCase("not an email address")]
//... and so on
public void TestSendEmailThrowsIfInvalid(string email)
{
    SendConfirmation("test", email);
    //Assert throws exception...
}

Okay, stop... do we really need to re-test every single valid and invalid email address? Data-driven tests make this easy, but that doesn't make it right. In this function, there are really only two paths that matter: an invalid email address throws an exception, and sending an email successfully. Let's try again:

public void TestSendEmailIfValid(string email)
{
    SendConfirmation("test", "validemail@test.com");
    //Assert sends email...
}
public void TestSendEmailThrowsIfInvalid()
{
    SendConfirmation("test", "not an email address");
    //Assert throws exception...
}

Mockists might even take this so far as to stub out the IsValidEmail function for the purposes of testing this function, but for this simple case, it might be overkill since IsValidEmail has no external dependencies to begin with.

In the real world, this kind of mistake is harder to spot. Generally, if you have an explosion of TestCase attributes covering all kinds of permutations, consider revisiting the code under test. There may be some opportunities to simplify both your code and your test suite.

JavaScript - apply invocation pattern part 2

2010-07-17T11:33:00.001-04:00

In my last post I promised a real-world example of the apply invocation pattern. The truth is it was getting late, and I didn't feel like writing anymore. However, one of my coworkers called me out, most likely because he's a JavaScript ninja and wants to put me in my place. In an effort to deny him the satisfaction, I'll steal an example from people who are smarter than I.

If you use jQuery, you've probably used the each function at some point. The each function works something like this (what follows is a vast oversimplification, see here for the actual implementation):

jQuery.extend({
  each: function(array, callback) {
    for (var i = 0; i < array.length; i++) {
      var value = array[i];

      //Apply callback with "this" as the current value
      callback.apply(value, [i, value]);
    }
  }
});

Now we can use the each function like this:

var sentence = '';
var words = ['hello', ' ', 'world', '!'];
jQuery.each(words, function() {
  sentence += this;
});
//sentence == 'hello world!'

Things your parents never told you about JavaScript - Apply invocation pattern

2010-07-13T22:10:00.002-04:00

So, yeah, it's been a while... okay, it's been more than a while. I'm sure my 8 followers missed me. Anyway, I recently had the opportunity to learn a whole mess of new stuff, and I wanted to start writing some of it down. I had a 3 week fling with Ruby, followed by a longer affair with JavaScript. I was a static language guy for the last 3 years, so all this dynamic nonsense had my head spinning... and you know what?

I liked it.

I always thought of JavaScript development as painful; a sort of necessary evil. Turns out there's an obscenely powerful language there, if you go looking for it (incidentally, start by looking here). Among those powerful features are first-class functions. For example, suppose I run the following code:

var greeter = {
  name: 'Mike',
  greet: function() {
    return 'hello ' + this.name;
  }
};

greeter.greet(); // -> 'hello Mike'

Nothing shocking there, right? Well, I can actually reach into the greeter object and steal the greet function:

var greet = greeter.greet;
greet(); // -> 'hello '

Okay, kind of cool, but not quite the expected result. Where did my name go? When you grab a function that references this and invoke it, you need to tell JavaScript what context you want to execute it in. The built-in JavaScript Function object has a method called apply which lets you set the value of this (it also lets you pass an argument array if you want to):

var bob = {
  name: 'Bob'
};

greet.apply(bob); // -> 'hello Bob'

This is called the apply invocation pattern. What can you do with it? That'll have to wait for another post...

Re-throwing exceptions in C#

2010-03-11T06:58:00.000-05:00

What is the difference between the following two blocks of code?

// #1
void HandleException()
{
    try
    {
        //Do something...
    }
    catch (Exception e)
    {
        throw e;
    }
}

// #2
void HandleException()
{
    try
    {
        //Do something...
    }
    catch (Exception e)
    {
        throw;
    }
}

Both blocks catch and re-throw an exception. The first block re-throws the caught exception, the second block does not specify anything to throw. The main difference between these blocks becomes apparent when the exception is logged higher up in the call stack. The stack trace for the first code block will be missing anything that came before the throw. The second code block will contain the full stack trace. This can be the difference between life and death when trying to diagnose an issue in production.

Castle Windsor: Order Matters

2010-01-06T06:50:00.001-05:00

I've been learning a lot about Castle Windsor lately. I ran into something that surprised me yesterday. Suppose you have the following class hierarchy:

interface Service
{
}

class ServiceA : Service
{
}

class ServiceB : Service
{
}

What do you think the output from this code will be?

var container = new WindsorContainer();

container.Register(Component
    .For<Service>()
    .ImplementedBy<ServiceA>());
container.Register(Component
    .For<Service>()
    .ImplementedBy<ServiceB>()
    .Named("serviceb"));

var service = container.Resolve<Service>();

Console.WriteLine(service.GetType().Name);

If you said ServiceA, then you were right! Now, what about the output from this code?

var container = new WindsorContainer();

container.Register(Component
    .For<Service>()
    .ImplementedBy<ServiceB>()
    .Named("serviceb"));
container.Register(Component
    .For<Service>()
    .ImplementedBy<ServiceA>());

var service = container.Resolve<Service>();

Console.WriteLine(service.GetType().Name);

If you said ServiceB, then maybe the title of this post gave the answer away. I expected the named service to be a special case. In other words, I thought asking for a Service implementation would always give me ServiceA, unless I specifically asked for ServiceB by name.

ASP.NET MVC XML Model Binder

2009-12-14T06:59:00.006-05:00

Update 12/14/2011
This is one of my most highly viewed posts. Unfortunately, this post applies to version 1 of ASP.NET MVC (it might also work with version 2 with some small modifications). If that is what you are looking for, then please read on! Otherwise, for more relevant coverage of this topic I recommend Jimmy Bogard's post

I needed a way to receive raw XML in my action methods, rather than form-encoded values. Model binding makes it a piece of cake:

In my action method all I have to do is apply the model binder attribute:

Now the edit action receives an XML string. Even better, I can get a strongly typed object if it is serializable:

Now my action method looks like this:

The model binder attribute is a little too verbose for my taste, so I wrote a custom model binder attribute:

Finally my action method is nice and readable:

"Good Enough" Test Automation

2009-12-08T07:00:00.000-05:00

If you are practicing Agile and you want to stay releasable at the end of every iteration, you must automate your tests. If you do not automate, one of two things will happen:

Your velocity will decrease each sprint as you need to reserve more and more time for regression testing.
You will not run (or will forget to run) regression tests, and you run the risk of breaking something unintentionally. Best-case, your testers will catch any problems before release. Worst-case, your customers will find problems after release.

Now, here's the fun part: you have 2-3 weeks to build and test something potentially releasable. How can you possibly squeeze test automation into that time frame? The same way you attack that next killer feature: start small and iterate.

A few days ago I was testing some changes to a multi-step online signup process. The current code base is, shall we say, less than testable at the unit level. As a result, all testing for this feature has been manual in the past. After a few manual test runs, introducing some automated tests at the browser level seemed like a good idea. I immediately thought about continuous integration, but quickly realized dealing with all the necessary data setup and tear-down was going to take several days to get right. All I needed at that moment was a script to fill out the forms and click through the whole process. I coded a short Watir script, ran it a few times, and visually verified the process still worked end-to-end.

If all you need is a script to do the boring, repetitive parts of testing for you, write the script. If the script is useful, you'll keep coming back to it, and eventually get it running under continuous integration. Just take the first step, choose a tool, and start automating.

Missing reports in CruiseControl.NET

2009-12-02T08:23:00.000-05:00

My team experienced a spell of build failures last week due to broken unit tests. It wasn't a big deal, broken tests happen from time to time, the breaker simply fixes them and life goes on. However, something strange happened when we looked at the build report to see what failed.

The report showed that the NUnit process had exited with an error code, but the unit test summary claimed that no tests had been run.

I logged in to the build server and checked out the build log. The unit test results were there, and I was able to search the log to find which ones failed, but obviously nobody wants to log in to the build server and search through a text file whenever a unit test breaks. On closer inspection, I realized that all of the XML data for the test results were wrapped in a CDATA section. One developer pointed out that this was likely caused by strange characters in the test results, and the documentation for the file merge task confirmed the possibility. However, my team has amassed about 2,500 unit tests, so finding the offending character in approximately 10,000 lines of test results would have been difficult to say the least.

After some digging, I found out that CruiseControl.NET logs a debug message when a file cannot be merged because it contains invalid XML. I opened up the log (ccnet.log by default) and a quick search for output is not valid XML revealed the exact line number in the test results that caused the file merge task to fail. Now we are happily integrating continuously once again.

Configuring NServiceBus In Web Applications

2009-11-25T08:22:00.000-05:00

My team recently started using NServiceBus for a new project. It has gone extremely well for the most part. Messaging can be tricky, and a tool like NServiceBus can lower the barrier to entry and gently guides developers towards messaging best practices.

Like any tool, NServiceBus has a learning curve, and there were a few problems along the way. The biggest was an issue with configuring web applications as endpoints. Each web application used the fluent configuration API in the Application_Start event handler like so:

NServiceBus.Configure.With()...

It worked fine in almost all cases. However, when one application was deployed to IIS, the configuration code was throwing inexplicable errors. My team lost about a week trying to figure out what was going on, and eventually started investigating workarounds in order to meet the deadline. Workarounds usually result in their own unique set of problems, which I desperately wanted to avoid. Finally, a long session with reflector revealed the problem:

NServiceBus.Configure.WithWeb()...

The difference between the two methods is subtle. The former tells NServiceBus to scan AppDomain.BaseDirectory for assemblies, while the latter tells NServiceBus to scan AppDomain.DynamicDirectory. The reason this affected one application in particular was because of how that application is deployed. Different versions of the application are deployed in virtual directories under the same web application in IIS, so there was a mismatch between some assembly versions.

The NServiceBus samples demonstrate the use of the WithWeb method. Had we paid more attention to the samples, we might have completely avoided this headache.