The interesting thing about writing a book such as Programming ASP.NET 3.5 is that as new readers come to it over time, they find that libraries used within the book code break the examples. Peter Ormshaw got in touch today to point out that the Ajax Control Toolkit has changed slightly since build 20229 which the book was built against.

In particular, he’s come across three differences between the book and working with v3.5.40412 which is the latest version at the moment.

Installing The Control Toolkit

Appendix A, which covers installing the control toolkit is now obsolete. Best practice now would be to download the binaries for the toolkit and follow the installation instructions at http://www.asp.net/ajaxlibrary/act.ashx.

You Must Use The Toolkit Script Manager

Any AJAX web form you’ve created in Visual Studio automatically contains the standard ASP.NET ScriptManager control. If you want to use any toolkit controls on that page, you must replace this with the toolkit’s own ScriptManager control. So then, you change this

<asp:ScriptManager ID="ScriptManager1" runat="server" />

to this

<asp:ToolkitScriptManager ID="ToolkitScriptManager1" runat="server">
</asp:ToolkitScriptManager>

Toolkit now uses asp as its TagPrefix: BulletedList Users Beware!

The final thing to note is that v40412 now has the Toolkit controls use “asp” as the default TagPrefix for its controls rather than cc1. This in itself is not a problem and makes sense as Microsoft have now more formally adopted the Toolkit with all its jQuery finery and finessing on the client side.

However, the toolkit also includes a control called BulletedList which, with the tagprefix change now means that Visual Studio will no longer compile pages referencing the toolkit and containing this control until you alter the TagPrefix used by the toolkit on that page. Typically, that means changing the “asp” in TagPrefix=”asp” in this line

<%@ Register Assembly="AjaxControlToolkit" Namespace="AjaxControlToolkit" TagPrefix="asp" %>

to something other than asp. Don Kiely has a full description and reasoning behind this issue at devproconnections.com.