One of the things I wanted to go for with NUnitAsp was to bring it forward with compatibility for ASP.NET v4; but also retain compatibility with ASP.NET v2.

There are some hurdles to jump over to make that work.

NUnitAsp disregarded compatibility with ASP.NET 1.x. I don’t mind that either. It’s old, had many performance issues, lacked 64-bit, and a boatload of other reasons to move on.

Moving off of ASP.NET v2 is harder though. ASP.NET v2 effectively existed until ASP.NET v4. Sure, the .NET Framework 3.0 and 3.5 came out since then – but it still remained ASP.NET 2.0. Fire up Visual Studio 2008, create a new Web Application, throw an exception and take a look what the version is listed. It’ll be 2-something. Lots of apps will be tied to this version for a bit longer.

Microsoft tends to keep with the old school versioning scheme, too. Big changes, possibly breaking changes, are reserved for major releases only. That isn’t the law of the land (they’ve done it), but it certainly seems to be there goal.

Thus, we effectively had the same version of ASP.NET; save a few added framework pieces such as AJAX and MVC; from November 2005 to April 2010.

Breaking changes happened in ASP.NET v4. Most of them were bug fixes reported by customers. One notable one is how a textarea is rendered if it begins with line endings.

Assuming a text area starts with empty line, then “Hello World!”

There is an important, subtle different there. The number of line breaks. Actual “rn” in the HTML. It’s one of the rare cases in HTML where it makes a difference. In ASP.NET 2.0 – this was a bug. Setup a simple page that has a textarea, and a button that does a simple postback. It doesn’t even need a click handler. Fire up a respectable browser such as Chrome, enter “Hello World!” preceded by an empty line. Now do your post-back. You’d be surprised that your return in the textarea is now gone. Do the same thing except with two empty lines, and you’ll see that only one disappears.

This was a bug in how ASP.NET v2 rendered a textarea. A textarea should always have a new line after the opening tag in order to preserve empty lines. ASP.NET did not follow that rule.

Those that have been bitten by it know it’s a pretty simple fix by creating your own TextBox control and fixing the rendering by implementing their own Render().

Now that it was fixed in ASP.NET; NUnitAsp was confused. Why are there extra line endings?

So this simple assertion for NUnitAsp would break in ASP.NET 4:

[Test]
public void ShouldHandleAspNet4Rendering()
{
    var text = string.Format("Hello World");
    multiline.Text = text;
    doPostBack.Click();
    Assert.AreEqual(text, multiline.Text);
}

With this error:

expected:<"Hello World">
but was:<"rnHello World">

You’d think the fix for this is simple. Just strip off the first 2 characters.

That would work under ASP.NET 4 for only; and only for Windows. It’s entirely possible that Mono would only render the line-feed (Unix style line endings). For ASP.NET v2; that might strip off 2 characters that shouldn’t be. More importantly, we can’t just trim them off because what if you wanted to write a test that asserted a textarea began with a new line?

This is where things got a bit sticky. There are two unknowns: Platform and ASP.NET version. The platform bit I am not entirely worried about. It is a legacy project, and NUnitAsp wasn’t designed with that in mind. The ASP.NET version is a doozy though. In order to know if the new line needs to be stripped off, we need to know what version of ASP.NET rendered it. There is no reliable way to detect the ASP.NET version purely from rendered markup. Knowing that, I weighed my options.

Ultimately, different builds is the solution I am going to go with. I’m not entirely sure how yet; but it’s in the works.