Advanced .NET Debugging

If you mix and match 32 bit machines/processes with 64 bit machines/processes in an ASP.NET load balanced environment and you are using the AJAXControlToolkit ToolkitScriptManager class you might end up with the following error:

Message: Assembly “AjaxControlToolkit, Version=1.0.10920.32880, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e” does not contain a script with hash code “9ea3f0e2″.
Stack trace: at AjaxControlToolkit.ToolkitScriptManager.DeserializeScriptEntries(String serializedScriptEntries, Boolean loaded)

at AjaxControlToolkit.ToolkitScriptManager.OnLoad(EventArgs e)
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

The reason is that the request being sent to retrieve the combined javascripts of the control used in the page contains a hash code that is used internally. That hash code is being generated from the script’s name using the default string.GetHashCode function which returns different values for 32 bit and 64 bit processes.

If your 64 bit process creates the javascript include call which contains the 64 bit hash code and the request will eventually reach the 32 bit process/machine you will get this error since the hash value will not be found internally and vice versa.

There is an open issue about this in CodePlex since late January but as of the time of this post, the latest source version in CodePlex doesn’t have a fix for this.

Perhaps its just another case of RTFM but I might have a point here. Really.

I was using AJAX.NET and wanted to attach some silly handler to the “onmousedown” event of a link (”<a href”). I used the nice little $addHandler method in the following syntax:

$addHandler(myElement, “onmousedown”, myHandler);

And to my surprise it didn’t hook up anything.

I did what any developer would do, plunged back to the documentation and after a bit of a careful reading I saw the following line:

“The eventName parameter should not include the “on” prefix. For example, specify “click” instead of “onclick”.”

Now why should I care if I’m writing “onclick” or “click”. The convention used in browsers is “onclick”, after all that’s what you put on an element if you want to add an “onclick” handler in HTML.

Why would anyone want to break this convention. And even if you do decide to break it, adding a simple “if” or checking for the characters “on” at the start of the string and removing them would be nice.

Anyhow, I quickly changed the code to:

$addHandler(myElement, “mousedown”, myHandler);

and everything started to work wonderfully.

At least I’ve learned something new, that the eventName passed to the $addHandler function should not contain the “on” prefix. I also re-learned again that I should always RTFM, even the fine prints in the “Remarks” section.

“Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.”

Have you ever got this kind of error when you are doing an Async postback using AJAX.NET (starting from Beta 2 if I’m not mistaken and going all the way to the current RC1 - at least at the time of writing this post) ?

It seems the newer versions of AJAX.NET really hates having “Response.Write” being called while doing an Async postback. It changes the response a bit causing it a hard time extracting the changed values and updating the changes using JavaScript on the client side.

If you get this error go through your page and all the controls in it (including controls within controls) and make sure you don’t have a “Response.Write” in the markup page.

Having “Response.Write” in the code behind in an event that is fired on an Async postback like Page_Load, Page_Render or the handler that handles that exact event can cause the same problem.

If you must use “Response.Write” you can get a similar solution by using a Label control and update it instead of using “Response.Write“.

If you use “Response.Write” in markup pages (ASPX or ASCX) replace them with either the “=” syntax (<% = MyProperty %>) or use the same solution mentioned above, adding a Label control and updating it in the code behind.