Getting started with ASP.NET AJAX in Visual Web Developer
Once you download ASP.NET AJAX, you are ready to start using Visual Web Developer and Visual Studio 2005 for your development.
The first thing you will notice when you open up Visual Web Developer is that you now have a new project type called ASP.NET AJAX Enabled Web Site as seen below.
Selecting this option will give you a web site with a different default.aspx and web.config than a regular ASP.NET web site. You’ll also have the ASP.NET AJAX Extensions pre-populated in your toolbox for easy drag and drop into the designer.
Tip: If you are going to be creating a lot of ASP.NET AJAX pages or are going to be adding ASP.NET AJAX extensions to your existing web site, you may want to create item templates out of your default.aspx and web.config files. In order to do this, you will use the Export Template wizard on the File menu. Choose Item Template in the wizard, select references as well as a default name and description for your templates and you are ready to use them over and over again.
Once you export your templates using the wizard, you will be able to see them in the Add New Item dialog as shown below.
Give Visual Web Developer a run for creating your ASP.NET AJAX web site and let us know your feedback.
Couple of gotchas that we’ve heard about to date:
1. One issue that people have been running into is with markup intellisense and source code preservation inside of the new controls like ScriptManager, UpdatePanel, etc. in HTML source view. This is a known bug that will be fixed in Visual Studio SP1 and there’s also a workaround that exists currently. See this post for more details regarding this issue and how you can work around it.
2. Another fairly common gotcha is to forget to change <compilation debug=”true”> to <compilation debug=”false”> in your web.config when you are ready to deploy your application. The default web.config template has debug=”false” but upon F5, Visual Studio will automatically change this to debug=”true” to enable you to debug your app. If you deploy your application without changing this back to debug=”false”, you are paying via both a higher payload as well as slightly degraded runtime performance.