Some changes of note from the ASP.NET AJAX 1.0 RC to RTM release; some of which may break your application after upgrading.
Yes, I'm a bit behind the announcements about the RTM release which I'm sure you could not have missed from Scott Guthrie, Nikhil Kothari, Shawn Burke, and Brian Goldfarb. However, I am just now working through all of the changes in the latest release.
I just finished reading the Changes between the ASP.NET AJAX ("Atlas") CTP and the RTM Releases whitepaper for the second time. The first time, I quickly scanned it for breaking changes that would affect me. The second time, I have taken more time to read through it and in the process make note of changes in the RTM release that directly affect applications I work on.
So, here is a short list of some of the changes mentioned in the whitepaper. You should be able to quickly scan through the headings below to find any items that are relevant for your applications. Hopefully, learning about these changes will save you some time and headaches.
Note: If you are looking for solutions to some common gotchas, see Scott Guthrie's excellent post, Links to ASP.NET AJAX 1.0 resources, and answers to come common questions.
Changes on the client...
If you have used the client-side queueScriptReference function
The Sys.Application.queueScriptReference method has been removed
If you use the client-side Debug class
The client Debug class has been renamed to Sys.Debug. This avoids any collision potentials with other frameworks.
The Sys.Debug class allows you to output debug information to the browser console, to the Visual Studio debugger output window, and in Internet Explorer, to a <textarea> element in the page. Sys.Debug supports methods to generate trace information, to throw an assert, and to display an object dump.
If you use the client library's Sys.ScriptLoader
The Sys.ScriptLoader type has been made private and all members of this type are therefore also private. This change has been made given the change to the model of rendering script references ... [see LoadScriptsBeforeUI attribute of the ScriptManager for more info]
If you use or have considered using the client function getLocation
Many fixes in the Sys.UI.DomElement.getLocation method have been made to accommodate variations in implementations across browser types and versions and to accommodate the nesting of elements, borders, margins and scroll.
If you are keen on browser compatibility
The CTP release used an abstraction model for browser compatibility that focused on APIs based on Internet Explorer. It used the server to provide a compatibility layer when the browser was not Internet Explorer, implemented by downloading an additional JavaScript file.
In the RTM release version, this abstraction is retained, but it is based on standards and other improvements to the design. As a consequence, server intervention is no longer required. Instead, the client contains simple browser detection code based on capability, and abstraction APIs and other component-based APIs use such abstractions.
If you were using the IFrame to make cross-domain calls
The IFrame executor. This feature provided support for cross-domain calls, and is not available in RTM release in part because of security concerns.
Changes to Application Configuration...
The system.web.extensions configuration section
System.Web.Extensions (other than the jsonSerialization section) are now marked to prevent their definition below the application root.
The system.web / pages / tagMapping section used for special validator controls must be removed ...
System.Web.UI.Compatibility namespace and the validator controls that were compatible with asynchronous postbacks have been removed.
Changes on the server...
If you use static page methods
Accessing static page methods from script is disabled by default. You will need to explicitly set EnablePageMethods=”true” flag on the ScriptManager for the PageMethods client proxy to be generated.
Script compression
Script compression is skipped if the browser is Internet Explorer 6.
If you've wanted more control over when client scripts are loaded
The ScriptManager control now supports a LoadScriptsBeforeUI property that allows page developers to have script references rendered at the bottom of the form rather than at the top (which is the default).
Control of script debug mode
By default, the ScriptManager control infers its debug or release setting from the current debug mode on the server. In the RTM release, this value is inferred only from the debug setting in the <compilation> section of the Web.config file in the application root. It is not read from the configuration hierarchy, as in previous releases.
About those validator controls required to make your controls compatible with the UpdatePanelControl
The validator controls that were created to be compatible with asynchronous postbacks have been removed. Instead, an update to the .NET Framework will be released that contains updated versions of these controls. This means that no new validators are required beyond those in the main ASP.NET server framework.
See Matt Gibbs' ASP.NET AJAX Validators post for more information.
If you have web services that are called from the client
In the RTM release, new server attributes are defined to specify particular behavior. This change was driven by security concerns and to avoid reusing existing attributes where the semantics are different.
Specific changes to Web method attributes are:
· [ScriptService] attribute is required on the Web service class in order for its methods to be called from client script.
· [ScriptIgnore] attribute excludes properties or fields from JSON serialization, so that they do not appear on script proxies for a server type. This corresponds to the [XmlIgnore] attribute in the CTP release.
· [GenerateScriptType( )] attribute generates script proxies for server types, in addition to types used as input parameters or return types on Web methods. This attribute can be added to the Web service class or to any Web service method. It corresponds to the [XmlInclude( )] attribute in the CTP release.
As always, if you want more details go to the Ajax.asp.net documentation page or check out the ASP.NET AJAX Forums.