7554 Views // 0 Comments // Not Rated

Getting ASP.NET AJAX (And The AJAX Control Toolkit) Working In SharePoint 2007 Service Pack 1

What??? SharePoint 2007 Service Pack 1 will support AJAX? Awesome! Even though I already have all my hacks and workarounds in place to get it to work, explicit support will be great! Not only will my development experience be a lot cleaner and easier, but the fact that Microsoft is supporting it means that it will be more readily adopted by clients.

My upgrade goal, therefore, was two-fold: first, I wanted to get ASP.NET AJAX working on SharePoint 2007 without any hacks. A hack, in this case, means any manipulation of update panels or script managers programmatically. Also, I want to avoid any modifications of master pages or page base classes. I should be able to take a user control that has AJAX controls, and use it seamlessly in my SharePoint web part pages.

Second, once this was working, I wanted to minimize the footprint required to enable AJAX. This means adding only settings that are absolutely required to the web.config file, only deploying proper assemblies to the GAC, and basically ensuring that I can come up with a procedure to upgrade any web app running SharePoint 2007 to Service Pack 1 with full AJAX support as quickly and efficiently as possible.

Here's my experience...

I started out by downloading the very low-key set up for the update. There are both MOSS and WSS versions, so make sure to get the right one. I installed it, and then kind of sat there. "That was too easy," I thought. Next I took my test control, riddled with AJAX Control Toolkit controls and update panels, and redeployed it to a page inside a SmartPart.

Yep. Too easy. Server error!

After several hours of tinkering around, I was able to whittle the problem down. I was getting all kinds of errors reminiscent of my first days working with AJAX: problems was code running in onPrerender, child controls not being able to find their update panel, the script manager getting drunk and pissing everyone off, etc.

What I discovered was, apparently, that the service pack was "supporting" AJAX on the configuration side, not necessarily on the programmatic side. In other words, it doesn't seem to be doing any of the things that ASP.NET AJAX and the AJAX Control Toolkit require (script managers, update panels, etc.) on the page. It looks like we'll still need a way to programmatically get these elements to our web parts.

However, like I said, configuration is taken care of. I only had to add a few lines of to the web.config file: one to wire up the HTTP handler for AJAX, another to reference the AJAX Control Toolkit assembly, and finally two more to register the" ajaxToolKit" and "asp" prefix tags (the asp one points to System.Web.Extensions for the update panel) for the controls.

So that's cool. Not only do we no longer have to import the massive skeleton web.config file that Visual Studio builds for AJAX-enabled web projects, but we also don't have to worry any more about its inevitable conflicts with SharePoint's own cryptic web.confie file entries. So configuration, sans a few minor copy-and-pastes, is taken care of. Which is nice, considering that configuration is a huge source of SharePoint headaches.

But now what about the aforementioned other half of the battle regarding the programming side of things? Well, I turned to the latest and greatest of the SmartPart for all that. Since I wanted to alleviate any "hacks" previously used to get this stuff to work, and all of my SharePoint content development is centered around user controls hosted in SmartParts, I figured I would embrace this rather than fight it.

I too was hoping that everything would magically work, but SharePoint is not a magical place. However, Service Pack 1 does indeed sprinkle some pixie dust on things. Although there is still some wiring involved, AJAX on SharePoint has gone from not worth it to fairly easy. And no more hacks! If you consider the SmartPart a hack to get this to work, then you really need to reassess your SharePoint developmental paradigm.

Here are the web.config entries I had to enter:

Code Listing 1

  1. <httpHandlers>
  2. ...
  3. <add verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" validate="false" />
  4. ...
  5. </httpHandlers>
  6. <assemblies>
  7. ...
  8. <add assembly="AjaxControlToolkit, Version=1.0.10301.0, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e" />
  9. ...
  10. </assemblies>
  11. <pages>
  12. ...
  13. <controls>
  14. <add tagPrefix="asp" namespace="System.Web.UI" assembly="System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
  15. <add namespace="AjaxControlToolkit" assembly="AjaxControlToolkit" tagPrefix="ajaxToolkit" />
  16. </controls>
  17. ...
  18. </pages>

One footnote: I purposely used not-too-sure-of-themselves words like "seems like" and "probably" and "I discovered" throughout this post. It's because it seems like this should probably work easier than I discovered it does. I don't know if there's a better way or if I (somehow) installed the update wrong or what. Please keep this in mind, and post a comment if you find something better. Thanks!

4 Tags

No Files

No Thoughts

Your Thoughts?

You need to login with Twitter to share a Thought on this post.