I’ve been using ASP.NET AJAX 4.0 quite a bit lately in ASP.NET 3.5 applications. I encountered two issues tonight, and I hope this post saves someone some grief.
The first problem has to do with referencing the ASP.NET AJAX 4.0 library within an ASP.NET 3.5 application, and the second was a surprising data binding issue using the DataView.
If you are looking for more information on ASP.NET AJAX 4.0, be sure check out my other articles on the site.
Issue 1 – The ScriptManagerProxy and CompositeScripts
The first issue I encountered was a client side error when using the DataView on a content page in my ASP.NET 3.5 SP1 application. This site utilizes master pages, so I’m using a WebForm, otherwise I probably would have just gone with a plain old HTML page. Regardless, since this is an ASP.NET application and the ScriptManager is declared in the Master page, I added the ASP.NET 4.0 AJAX scripts to a ScriptManagerProxy (instead of the ScriptManager itself). The code for the ScriptManagerProxy looks very similar to that for the ScriptManger.
I then proceeded to run the page, getting two errors, **Type._registerScript is not a function **for both MicrosoftAjaxTemplates.js and MicrosoftAjaxAdoNet.js. Seems like MicrosoftAjax.js isn’t being loaded. When using ASP.NET AJAX 4.0, we need to ensure that it uses the 4.0 version of MicrosoftAjax.js. Looking at FireBug’s Net tab, I confirmed that the 4.0 version of MicrosoftAjax.js wasn’t being loaded. I didn’t understand why not, until I revisited the Master Page. The ScriptManager code was using a CompositeScript, useful to save a bit of bandwidth, but that ended up causing the problem. Here’s the offending code:
By adding the 3.5 MicosoftAjax.js to the CompositeScript, it made it so the ScriptManagerProxy couldn’t load the correct version of that file. I simply removed that ScriptReference from there and everything loaded correctly. Of course this means that MicrosoftAjax.js isn’t being compiled into a nice composite script package, but if that’s what needs to be done to use the 4.0 scripts (at least for now), that’s fine.
Issue 2 – Incorrect Field Name
I found this to be very odd behavior. If you add binding syntax for something that doesn’t exist in the data context, the DataView control just flat out won’t render any data. No error, just no content. This seems silly. I would expect the DataView to render the content it can, and use a null or empty string for things it can’t bind.
So let’s say you are using ADO.NET Data Services and the object coming back has a couple of fields like Name, Address1, and Address2. Then you try to bind to , which doesn’t exist in the object (whoops, forgot the “1” after that field), you end up looking at very empty HTML. Nothing gets rendered. Stupid mistake, yes (wouldn’t it be nice to have Intellisense when binding), but a very bizarre way of handling this sort of thing. Lesson here, if you don’t see any content when the template loads, check the fields you are binding to.