Steve Sanderson’s blog

This week Apress is sending the second edition of my ASP.NET MVC book to the printers. Hopefully this means you can get your hands on physical copies by the end of this month.

The first edition went deep into the details of the MVC Framework, providing both tutorials and reference material. Judging by sales and review scores, it was a success. The second edition:

• … is thoroughly updated for ASP.NET MVC 2. It explains all the new features, including templating, metadata, validation, asynchronous controllers, areas, HTTP method overloading, strongly-typed input helpers, default parameters, etc., and many are demonstrated in the various tutorials.
• … is updated to account for .NET 4 and Visual Studio 2010. Even though .NET 4/C# 4 is the preferred technology throughout the book, all the documentation and code accounts for readers using .NET 3.5 as well.
• … is updated to reflect more recent patterns and best practices. For example, discussions of automated testing apply ideas from Behaviour Driven Development (BDD) where relevant, and tutorials and descriptions now consistently distinguish between view models and domain models.
• … is updated in light of reader feedback from the first edition. Certain explanations and terminology are overhauled, and the tutorials make use of more effective third-party libraries (e.g., Ninject for Dependency Injection).

This blog post is partly intended to build awareness of the new book, and is partly intended to deal with some of the questions I regularly get by email. So, here are some questions that people frequently ask:

Is this a new book, or an update?

It’s an update of the first edition. The following diagram should clarify what proportions of the book are new, dramatically changed, or just refreshed:

Where and exactly when can I get it?

I don’t know the exact date when it will ship; this depends on physical production and distribution schedules that are beyond my knowledge.

• For printed copies, your best bet is to pre-order with Amazon. Hopefully these will ship around the end of June, but I can’t guarantee it.
• For the eBook version, keep checking the Apress web site.

There’ll probably be a Kindle version in due course, too.

If I already have the first edition, should I buy the second edition?

If you use ASP.NET MVC regularly - especially if plan to use the new MVC 2 features but haven’t yet learned about them in depth - you may well get a lot out of reading the new edition and seeing what’s the same and what’s new. You may also have colleagues who need a deeper knowledge of the whole MVC Framework, including both v1 and v2 features.

However if you don’t use ASP.NET MVC much and don’t intend to migrate your development to v2, perhaps there isn’t such a strong case for buying an update of a book you already own.

Some readers have asked if they can get a sort of “upgrade” edition which contains only the new material. That wouldn’t really make sense for this book, as the new concepts and practices are applied throughout. I don’t present “old” material followed by “new” material – the whole manuscript is updated as a single coherent guide to ASP.NET MVC 2 from the beginning as I believe this gives the clearest understanding.

What new and updated in the second edition?

There are far too many updates and enhancements in the new edition to describe them all. Here’s a brief outline of the table of contents and roughly how each chapter has changed.

Chapter 1: What’s the Big Idea?

Updated to account for ASP.NET 4, including improvements to WebForms and how this impacts the comparison between the two frameworks. Gives an overview of what’s new in ASP.NET MVC 2. Changed the discussion general software development practices to account for more recent trends.

Chapter 2: Your First ASP.NET MVC Application

Tutorial now accounts for your choice of Visual Studio 2008 or Visual Studio 2010. Uses new ASP.NET MVC 2 features, including empty project template, automatic HTML encoding, and Data Annotations validation. Streamlined the flow of the tutorial to improve readability.

Chapter 3: Prerequisites

Describes newer architectural patterns including MVVM. Discussion of automated testing expanded to cover integration testing as well as unit testing, and demonstrates Cucumber-style BDD testing and explains the tradeoffs between this and traditional unit TDD. Various updates to terminology and explanations.

Chapter 4, 5, 6: SportsStore tutorial

Now accounts for your choice of Visual Studio 2008 or Visual Studio 2010. Improved the code: better project structure, uses Ninject instead of Castle Windsor for DI, has better unit test naming (BDD-style) with a clearer description of the limitations of such testing. Applies the viewmodel pattern and related terminology more consistently.

Adapted the tutorial to benefit from MVC 2 features including optional parameters, metadata, scaffolding, client-side validation, automatic (de)serialization, etc. Some parts of the tutorial now go in a different order to make it easier to follow.

Chapter 7: Overview of ASP.NET MVC Projects

Updated to account for ASP.NET MVC 2’s two project template options (empty and non-empty), and for changes in the core ASP.NET 4 platform regarding configuration and deployment.

Chapter 8: URLs and Routing

Now covers areas – reasons for using them, setting them up, their impact on routing, how to avoid common problems, how to unit test their routing configuration. Explains how .NET 4 changes where the routing code lives and how ASP.NET MVC 2 deals with controller namespaces. Many smaller changes.

Chapter 9: Controllers

The 1st edition’s “Controllers” chapter is now split in two – this first chapter now covers introductory topics – receiving input data with parameter binding etc, producing output with action results etc., unit testing.

Has many changes to account for ASP.NET MVC 2, such as its enhancements to TempData. Also describes .NET 4 features – using optional parameters (and how these differ from ASP.NET MVC 2’s parameter defaults), using “dynamic” as a model type, etc. Expands the coverage of unit testing, demonstrating 5 ways to make mocking controllers easier.

Chapter 10: Controller Extensibility

The 1st edition’s “Controllers” chapter is now split in two – this second chapter now covers more advanced topics – custom filters, method selectors, controller factories, etc.

Updated to reflect changes in the ASP.NET MVC 2 request-processing pipeline, new built-in filters, HTTP Method Overriding, etc. Adds (a lot of) coverage of asynchronous controllers – not just how to use them, but how to measure their impact and avoid common misconfiguration problems.

Chapter 11: Views

Goes into detail about how automatic HTML encoding works. Coverage of HTML helper methods expanded for ASP.NET MVC 2 (there’s now over 50 helpers, and that’s before you even start counting all their different overloads). Explains new ways to render partials.

Chapter 12: Models

Most of this massive chapter is totally new, and goes into great detail about metadata, templating, and validation. Covers how the built-in templates work, creating custom ones, using HTML field prefixes, implementing custom metadata sources, consuming metadata, custom validation providers, custom client-side validation, doing all this inside a multi-tier architecture, etc.

The explanation of model binding and value providers is significantly updated to account for the new architecture in ASP.NET MVC 2.

Chapter 13: User Interface Techniques

This new chapter inherits UI-related material from various parts of the 1st edition book, including wizards, CAPTCHAs, child actions, master pages, open-source view engines, custom view engines. All updated to match ASP.NET MVC 2, of course.

Chapter 14: Ajax and Client Scripting

Updated various aspects of the code and explanations to account for new framework features, and to make things work with more recent versions of IE. Expanded the coverage of JSON data services, including security issues and ways to handle cross-domain requests. Some recommendations are updated to account for client-side performance considerations(browser’s rendering pipeline, CDNs, etc).

Chapter 15: Security and Vulnerability

Mostly the same as in the first edition. Shows an alternative tamper-proofing mechanism using MVC 2 code, plus describes JavaScript string encoding and its relation to script injection. Various code changes to fit in with ASP.NET MVC 2.

Chapter 16: Deployment

Radically restructured chapter – now all organized with step-by-step guides and checklists for each targeted IIS version, so now you only have to read the material relevant to you. Covers new deployment options, including combinations of .NET 3.5 SP1, .NET 4, Server 2003, Server 2008, Server 2008 R2, Server 2008 R2 Core, shared hosting, classic/integrated pipeline mode, etc. Accounts for many changes to these deployment environments since the 1st edition, including IIS 7.5-specific issues

Clearer explanations of various IIS request-processing mechanisms. A new section describes VS2010’s improved publishing and packaging mechanisms, config file transforms, etc.

Chapter 17: Using ASP.NET Core Platform Features

Mostly the same as in the first edition. Updated to account for ASP.NET MVC 2, IIS 7.5, with tweaks to code and explanations. Information about configuration APIs moved from Deployment chapter into this chapter.

Chapter 18: Migrating Existing Applications to ASP.NET MVC 2.0

Various updates relating to .NET 4 / VS2010 / ASP.NET MVC 2, including how to upgrade Web Forms applications to support MVC, using routing when combining MVC with Web Forms (both on .NET 3.5 and .NET 4), ways you can use Web Forms server controls with postbacks in MVC 2, should you wish to.

New section describes upgrading from ASP.NET MVC 1 – using automated tooling, doing it manually, a post-upgrade checklist, workarounds for potential problems.

OK, enough details

Of course, there are other ASP.NET MVC 2 books in the pipeline too. No doubt you’ll enjoy and benefit from any of them.

If you subscribe to this blog, you may have noticed that I’ve been writing about test automation methods a lot lately. You could even think of it as a series covering different technical approaches:

• Hosting your app in a real web server and testing it through a real web browser using WatiN (plus, in this case, SpecFlow for Cucumber-style specifications)
• Hosting your app in a real web server and testing it with client-side automation using Microsoft’s Lightweight Test Automation Framework
• Hosting your app directly in the test suite process and bypassing both the web server and the browser entirely using my MvcIntegrationTestFramework experiment
• Unit testing code in isolation – best and worst practices, and why I think unit testing isn’t applicable to all types of code
• Injecting code across process boundaries to assist integration testing approaches that host your app in a real web server, using Deleporter

The reason I keep writing about this is that I still think it’s very much an unsolved problem. We all want to deliver more reliable software, we want better ways to design functionality and verify implementation… but we don’t want to get so caught up in the beaurocracy of test suite maintenance that it consumes all our time and obliterates productivity.

Yet another approach

Rails developers (and to a lesser extent Java web developers) commonly use yet another test automation technique: hosting the app in a real web server, and accessing it through a fast, invisible, simulated web browser rather than a real browser. This is known as headless browser automation.

How is this beneficial?

• It’s faster than driving a real browser. The simulated browser is just a native code library, so it’s very quick to launch and shut down, doesn’t require interprocess communication with your test suite, and doesn’t waste time physically drawing things on your screen, opening and closing pop-up windows, etc. Nonetheless, the simulated browser is full-featured: it exposes the usual HTML DOM API, runs JavaScript, evaluates CSS rules, and so on, so it’s still an effective way to specify rich client-side behaviours.
• It’s more reliable than a real browser. Real browsers are complicated. For example, if you launch and shut down Firefox many times in rapid succession, occasionally it will fail to launch because a previous instance is still locking some file. Simulated browsers are totally independent, so don’t suffer these kinds of weirdness.
• You can get more low-level control if you want it. For example, the simulated browser can easily offer an API to alter the HTTP headers it sends, or let you get or set the contents of its cache. A real browser wouldn’t usually make this easy.

And what drawbacks might you expect?

• It can be harder to debug. Because you can’t physically see the browser on your desktop, it’s not as obvious what’s happening if a test fails (or passes) unexpectedly. Your debugger’s “immediate mode” will let you call the browser’s API to figure things out, but it can be a longer investigative process.
• There’s no absolute guarantee that it faithfully replicates a real-world browser. For example, HtmlUnit can simulate multiple versions of Firefox, Internet Explorer, and Netscape, but it may not simulate every single quirk.

About HtmlUnit

HtmlUnit is a headless browser automation library for Java. It’s very well-developed and mature, as you can see from its extensive API. (Need to configure whether the user has JavaScript on or off? No problem.) It’s also the same technology that underlies Celerity, a Ruby library that exposes the Watir API but runs faster.

Unfortunately, in .NET world, we don’t have any good headless browser automation libraries like HtmlUnit that I know of. But don’t let that stop you! We do have IKVM – a near-magic way of running Java code on .NET (either by hosting a JVM on the CLR at runtime, or by a one-time conversion process that generates a native .NET assembly directly from the Java bytecode). So, why not use HtmlUnit itself?

Converting HtmlUnit to .NET

It’s surprisingly easy to get HtmlUnit, a Java library, converted into a native .NET assembly (no Java Virtual Machine needed!) using IKVM.

First, download HtmlUnit (as a compiled JAR file) from SourceForge (I’m using version 2.7), and extract all its files from the ZIP archive.

Second, download IKVM binaries from ikvm.net/SourceForge (I’m using version 0.42.0.3), and again extract all its files from the ZIP archive.

Open a command prompt, ensure you’ve added IKVM’s /bin folder to your PATH variable, change directory to HtmlUnit’s /lib folder, and then run ikvmc to convert the Java bytecode of all of the HtmlUnit JAR files into .NET bytecode. I ran this command:

ikvmc -out:htmlunit-2.7.dll *.jar

This produced a lot of warnings and a large (~10Mb) .NET assembly called htmlunit-2.7.dll. If you don’t want to bother with this process, you can download my sample project (linked below) which contains the .NET assembly I generated.

Using HtmlUnit from .NET

Once you’ve got htmlunit-2.7.dll as a .NET assembly, you can use it with any .NET unit testing library such as NUnit or XUnit. You will also need to reference a few of the IKVM runtime assemblies (I narrowed it down to six additional IKVM assemblies that appear to be needed – these are all included in IKVM’s /bin folder).

As a trivial example, here’s how you can use HtmlUnit with NUnit to load the Google homepage:

[TestFixture]
public class GoogleTests
{
    private WebClient webClient;
    [SetUp] public void Setup() { webClient = new WebClient(); }
 
    [Test]
    public void Can_Load_Google_Homepage()
    {
        var page = (HtmlPage)webClient.getPage("http://www.google.com");
        Assert.AreEqual("Google", page.getTitleText());
    }
}

Slightly more interesting, here’s how you can fill out a form (again, Google Search), click a button, and inspect the results:

[Test]
public void Google_Search_For_AspNetMvc_Yields_Link_To_Codeplex()
{
    var searchPage = (HtmlPage)webClient.getPage("http://www.google.com");
    ((HtmlInput)searchPage.getElementByName("q")).setValueAttribute("asp.net mvc");
    var resultsPage = (HtmlPage)searchPage.getElementByName("btnG").click();
 
    var linksToCodeplex = from tag in resultsPage.getElementsByTagName("a").toArray().Cast<HtmlAnchor>()
                          let href = tag.getHrefAttribute()
                          where href.StartsWith("http://")
                          let uri = new Uri(href)
                          where uri.Host.ToLower().EndsWith("codeplex.com")
                          select uri;
    CollectionAssert.IsNotEmpty(linksToCodeplex);
}

As you can see, the API is full of Java idioms and feels a bit odd to a .NET developer. It would be great if someone decided to create a .NET wrapper library to expose a nicer API, .NET-style PascalCase, better use of IEnumerable and generics so LINQ queries were simpler, etc.

The other side of it is that HtmlUnit is very powerful. You can trivially scan the DOM with XPath, search for child elements, invoke events, much more easily than with WatiN.

To show that HtmlUnit has great JavaScript and Ajax support, here’s an example of automating a jQuery AutoComplete plugin to check its suggestions:

[Test]
public void jQuery_Autocomplete_Lon_Suggests_London()
{
    // Arrange: Load the demo page
    var autocompleteDemoPage = (HtmlPage)webClient.getPage("http://jquery.bassistance.de/autocomplete/demo/");
 
    // Act: Type "lon" into the input box
    autocompleteDemoPage.getElementById("suggest1").type("lon");
    webClient.waitForBackgroundJavaScript(1000);
 
    // Assert: Suggestions should include "London"
    var suggestions = autocompleteDemoPage.getByXPath("//div[@class='ac_results']/ul/li").toArray().Cast<HtmlElement>().Select(x => x.asText());
    CollectionAssert.Contains(suggestions, "London");
}

In case you want to download all this code as a demo project you can run without needing IKVM or Java or anything weird, I’ve put it on GitHub.

Summary

This is experimental! I haven’t used this on any real project, though it was pretty effortless so far, so I’d definitely consider it. I don’t know how much faster HtmlUnit would be than a real browser, but it does bypass the trickiness of real browsers, which may be worth it alone. If I was going to use it seriously, I’d definitely make some .NET wrapper classes to hide the Java naming and idioms. HtmlUnit on .NET feels robust, but I haven’t pushed it hard.