Update: After looking into this a bit further I found the problem doesn't exist in the Microsoft Ajax Library 3.5 (the same library bundled with ASP.Net 3.5). The same fix I propose here is implemented in that version...go me! Bill Gates must read my blog ;-P. So if you can upgrade, go for that, but I'd imagine for most people an upgrade of their framework is out of the question. In that case you can run the ajax libraries from source and implement the code change suggested here otherwise I stumbled accross an alternative workaround: On the ScriptManager tag you can change the ScriptMode property to 'release'. This means the rest of the site will use the project configuration compilation mode but the release version of the script files will always be loaded.
I’m using an ASP.Net Ajax UpdatePanel to refresh a field asynchronously. When the async post back is triggered I receive this error and my field doesn’t get updated:
Sys.ArgumentNullException: Value cannot be null. Parameter name: postBackElement
When I run in release mode <compilation debug="false"> there is no error to be seen.
In order to debug this one I needed to configure Microsoft Ajax libraries to run from source script rather than embedded resources (in hindsight I could have analysed the functions in my javascript debugger [venkman], but running from source makes viewing the code in the debugger much less painful, especially when you don’t really know where to start looking).
So after setting the debugger to break on any exception I replicated the problem. The exception is raised in a function called BeginRequestEventArgs in MicrosoftAjaxWebForms.debug.js:
Sys.WebForms.BeginRequestEventArgs = function Sys$WebForms$BeginRequestEventArgs(request, postBackElement) {
/// <param name="request" type="Sys.Net.WebRequest"></param>
/// <param name="postBackElement" domElement="true"></param>
var e = Function._validateParams(arguments, [
{name: "request", type: Sys.Net.WebRequest},
{name: "postBackElement", domElement: true}
]);
if (e) throw e;
Sys.WebForms.BeginRequestEventArgs.initializeBase(this);
this._request = request;
this._postBackElement = postBackElement;
}
The call to _validateParams returns the ArgumentNullException because postBackElement is null. So why doesn’t it error when I have <compilation debug=”false”>? Something I learned was that Microsoft Ajax uses optimized .js code for release builds - the exception is not thrown when we have <compilation debug=”false”> because the release version of the script (MicrosoftAjaxWebForms.js) looks like this:
Sys.WebForms.BeginRequestEventArgs = function(b,a)
{
Sys.WebForms.BeginRequestEventArgs.initializeBase(this);
this._request = b;
this._postBackElement=a
};
As you can see the parameter validation is non-existent (I have formatted it here for readability but in the actual file there is no white-space or formatting characters).
So what do we do from here? Well because I found that my code worked with no problems when in release mode I figured that it must be safe for postBackElement to be null. I modified the function to be less strict on the parameters it gets passed:
Sys.WebForms.BeginRequestEventArgs = function Sys$WebForms$BeginRequestEventArgs(request, postBackElement) {
/// <param name="request" type="Sys.Net.WebRequest"></param>
/// <param name="postBackElement" domElement="true" mayBeNull="true"></param>
var e = Function._validateParams(arguments, [
{name: "request", type: Sys.Net.WebRequest},
{name: "postBackElement", domElement: true, mayBeNull: true}
]);
if (e) throw e;
Sys.WebForms.BeginRequestEventArgs.initializeBase(this);
this._request = request;
this._postBackElement = postBackElement;
}
By passing the ‘mayBeNull’ property to _validateParams we can tell it to relax a little. So until I get some sort of ‘object is null’ error I’m happy with this. I’ll seek out a Microsoft bug report site somewhere and throw the info at them – hopefully they’ll have a better idea of the ramifications of the change above but it certainly doesn't look too intrusive.
I might try trace why postBackElement is null in the first place – I’ll post my findings.
Jimmy