Wednesday, January 31, 2007

Functional and load testing of ASP.NET Ajax applications – part I


Velodoc is developed in ASP.NET C# 2.0 with Visual Studio .NET 2005.

VSTS comes with unit testing, web testing and load testing, considering load testing is actually an execution environment for unit tests and web tests.

Unfortunately Visual Studio web tests work at the protocol level, recording HTTP traffic in order to replay it. The same applies to Redgate’s ANTSLoad and many other load testing tools. Velodoc is an Ajax application and this does not work.

We have started our search for a solution from the following lists of testing tools:

Obviously there are tools like Mercury Winrunner/Loadrunner and the IBM Rational equivalents which certainly cope but they are too expensive.

Our requirements are the following:

  • Test ASP.NET applications
  • Works on Windows XP with IE
  • Compatible with NetAdvantage controls, iFrames, file uploads and Ajax
  • Scripts IE including IE dialogs to drive functional UI tests
  • Several instances can be executed concurrently to create load/stress tests
  • Uses a familiar technology (low learning curve)
  • Open source is a plus and a requirement if the supplier has not been around for a long time.

There are three types of solutions which cope more or less with these requirements:

  • Macro recorders/players
  • Test environments
  • Web application scripting frameworks

Macro recorders/players and test environments

Searching on Tucows, and other shareware web sites reveals loads of macro recorders. Most of them hook the message pump and replay the windows messages. Obviously, the result is not good. We have tried a dozen of them but only iOpus iMacros 5.2 could do a decent job at automating a file upload from The code is reproduced below:

SIZE X=876 Y=627
TAG POS=1 TYPE=TEXTAREA FORM=NAME:aspnetForm ATTR=ID: MessageTextBox CONTENT= Test<SP>with<SP>iMacro
WINCLICK X=100 Y=429 CONTENT=C:\test.bin

I see at least three drawbacks to using iOpus iMacros as a functional test tool:

  • The lack of assertions and reporting capabilities makes it insufficient for functional testing;
  • The lack of infrastructure makes it insufficient for load testing;
  • The proprietary language reduces the possibilities despite the fact that it can call external scripts or be called via a COM component.

I have also tried several test environments mentioned in the above lists. Generally, recording the file upload test on has always proved difficult but I cannot tell whether it was feasible or not for some of them. I have limited myself to 2 hours per evaluation and the inherent complexity and learning curve was not worth digging passed first impression.

Web application scripting frameworks

I have looked at two open-source frameworks, which both script IE to execute functional tests on the web application:

  • IEUnit 2.3, a framework based on JavaScript
  • WatiN 0.9.5, a framework based on C# .NET

Both frameworks are very easy to start with due to a familiar language and an intuitive API. Additionally both frameworks provide the necessary assertions to report on the success or failure of a test fixture.

Scripting a file upload on the Velodoc home page with IEUnit entails the following JavaScript code:

_.setTextArea("MessageTextBox", "Test with IEUnit");
var fname = "C:\\test.bin";
var cmdShell = new ActiveXObject("WScript.Shell");
cmdShell.Run("C:\\EnterFileName.sbk " + fname, 0, false);

Where EnterFileName.sbk contains:

var fpath = " " + WScript.Arguments(1);
var popupWin = _.waitForWindow("Choose file", 30000);
_.findWindow(popupWin, "Edit").sendText(fpath);
_.findWinButton(popupWin, "&Open").click();

Scripting a file upload on the Velodoc home page with WatiN entails the following C# code:

using (IE ie = new IE(
ie.TextField(Find.ById("MessageTextBox")).TypeText("Test with WatiN");
Frame f = ie.Frame(Find.ById("FileUploadFrame"));
FileUpload fUp = f.FileUpload(Find.ById("FileInput"));
ie.CheckBox(Find.ById("SendTermsCheckBox")).Checked = true;
SimpleTimer t = new SimpleTimer(60 * 60);
Span s;
s = ie.Span(Find.ById("DownloadLinkLabel"));
if (!String.IsNullOrEmpty(s.Text))
goto EXIT;
} while (!t.Elapsed);
throw new WatiN.Core.Exceptions.TimeoutException("...", 60 * 60));
Assert.AreEqual(true, s.Text.Contains(;


The beauty of WatiN is that it builds on top of C# and .NET framework. Accordingly you get not only a rich language but also a rich environment. Test code built with WatiN can be executed within NUnit and Visual Studio unit testing projects which means that they can also be executed for load tests which I am going to try next although we know already that launching several instances of IE has its own limitation.

Wednesday, January 24, 2007

Remapping the universe

Following our recent post regarding Bumptop, see in the following Video Jeff Han and Phil Davidson demonstrating how a multi-touch driven computer screen will change the way we work and play.

Source: YouTube

Read the full article.

Tuesday, January 16, 2007

SGen XmlSerializers

My VS2005 C# web project was perfectly working in my development environment but I got the following error after deploying in a production environment:

Configuration Error
Parser Error Message: Cannot deserialize [C:\data.xml].

Using the fusion log viewer (FUSLOGVW.EXE) reveals a binding exception to Assembly.XmlSerializers.dll, where Assembly is the name of the assembly which contains the classes serialized in data.xml.

My ASP.NET application runs as a dedicated application pool under the credentials of a windows user which has very limited rights. The problem is related to the user rights which prevent the ASP.NET process from automatically generating XmlSerializers.

Visual Studio cannot generate XmlSerializers

On the build tab of your VS project properties, there is an option called “Generate Serialization Assemblies” which you can set to “On”.

If you look at MSBuild commands in the output window, doing so actually adds a command line which looks like the following:

C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\bin\sgen.exe /assembly:"Assembly.dll" /proxytypes /reference:"reference1.dll" … /reference:"referenceN.dll" /compiler:/keycontainer:VS_KEY_5EFB7881D71082EDCF85DBBFCD748B9A /compiler:/delaysign-

Note the /proxytypes option which actually prevents SGen from generating your XmlSerializers as specified in the documentation for the XML Serializer Generator Tool (Sgen.exe).

Use SGen as a post-build event

As a consequence you need to add the SGen command as a custom post-build event on the Build Events tab of your VS project properties:

"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\sgen.exe" /force /assembly:"$(TargetPath)" /compiler:/keycontainer:VS_KEY_5EFB7881D71082EDCF85DBBFCD748B9A /compiler:/delaysign-

Other interesting links

Thursday, January 04, 2007

Unable to validate data error in relation to machine key

I have experienced the following error on a production web site:

Unable to validate data

at System.Web.Configuration.MachineKey.GetDecodedData (Byte[] buf, Byte[] modifier, Int32 start, Int32 length, Int32& dataLength)

Searching on the web, many developers seem to solve the problem at least partially by generating a static key as described in Microsoft's knowledge base.

This is a workaround but not an actual solution to the problem, at least in my scenario where my application runs in a dedicated application pool under limited privileges as described in

The fix is to run aspnet_regiis.exe –ga DOMAIN\USER where USER is the identity of the application pool. Also make sure the user is part of the IIS_WPG group.

This command gives not only access to the IIS metabase but also creates the registry keys required in


for the application pool to generate machine keys.