When you think of deploying a web application, you may just think of the physical steps necessary to move the application from a development or test machine to the production machine. But of course, there is more to it. In this chapter, you will see that there are really three phases to deployment: preparing for deployment, the deployment itself, followed by monitoring and tuning an application.
Once the application is developed and tested, you need to prepare it for deployment. You can think of this as a pre-deployment checklist. There are a common set of pitfalls that can be avoided by checking and double-checking some settings before proceeding to deployment that will save you time in the long run. You also need to ensure that the production servers have the necessary bits to handle the deployment without error.
The development environment and the production environment are often different. They have different hardware, separate database backends, and unique connection strings. The Web Deployment projects provide an environment for automating the process of deploying your application from a test or development environment into production.
And once the application is in production, you need to know how it is behaving and potentially find ways to optimize for better performance. This chapter offers some options for tuning ASP.NET AJAX for maximum throughput. By leveraging client and server caches, an application can appear faster to the user and significantly reduce the load on the server.
There are several pieces to the ASP.NET AJAX functionality. The core ASP.NET AJAX release will ship as part of the .NET Framework in the next release. The CTP will continue as a sample of current investigations and prototypes the team is engaged in. And the ASP.NET AJAX Toolkit is a set of shared source behaviors and control extenders that are central to writing richer web applications. These elements build on top of the platform pieces to provide the key pieces necessary to push web development further.
In early preview builds, it wasn’t necessary to install the assembly into the GAC (Global Assembly Cache), but as features were added and refined, it became necessary to be able to assert full trust in order to maintain functionality. Assemblies in the GAC are considered trusted because they must be installed by an administrator. This allows the AJAX Extensions to get access to configuration data and use reflection, both of which are necessary for full functionality. We hope that most hosting providers will install ASP.NET AJAX for use by their clients, so if you use a web server managed by a third party, you must ensure that this has been installed on their servers. To download the latest release of ASP.NET AJAX, visit http://ajax.asp.net/downloads/default.aspx?tabid=47.
You can install ASP.NET AJAX on a server with the default settings without needing to interact with a UI with this command line:
msiexec /i ASPAJAXExtSetup.msi /quiet
One key thing to note with this release is that Microsoft has made the source code available for download. You can actually set a breakpoint and step from your code right into the ASP.NET AJAX platform code and out again. This certainly beats using tools to look at the il (intermediate language) code and try to interpolate when something is not behaving as you would expect. Now you can trace through the code execution from beginning to end. See http://go.microsoft.com/fwlink/?LinkID=82291 to download the source and symbols. If you spot a bug, please report it on the forums: http://forums .asp.net/default.aspx?GroupID=34.
When you deploy an ASP.NET AJAX application, there is no automatic check that ASP.NET AJAX is installed. If you are deploying to a hosted environment on the web, check to see that they have installed ASP.NET AJAX.
The ASP.NET AJAX Control Toolkit builds on the ASP.NET AJAX Extensions. The Toolkit is a shared source project, meaning that you can download the source code, compile it on your own, and make changes to the source. You can even contribute bug fixes or new pieces of functionality. You can find the Toolkit here:
The Toolkit contains a set of controls and control extenders with an impressive set of rich behaviors. For example, the ModalPopup control dims the page except for the new layer with the pop-up content. This effect is shown in Figure 10-1.
This is just one example out of a long list of controls and control extenders. The effects range from drag-and-drop support, to animations, to an autocomplete textbox, as well as rounded corners and drop shadow effects.
The Toolkit does not require installation into the GAC. Instead, you deploy it by simply copying the AjaxControlToolkit.dll into the bin directory of your web application. The controls work in partial trust environments and can be used in hosted environments where permissions are limited.
The Futures Community Technical Preview (CTP) is used to distribute new ASP.NET AJAX functionality that isn’t quite ready for final release. The CTP is not supported by Microsoft’s Product Support Services, but the ASP.NET team answers questions about it in the forums. The team starts work on a feature and solicits feedback by having volunteers download the CTP to give it a try. In this manner, many developers will have a chance to shape the future. There is no guarantee, however, that the features being shown in the CTP will eventually become part of a supported release, so you should use caution in writing your applications so you don’t become dependent on something that may be obsolete someday. The Futures CTP also installs a new site template into Visual Web Developer, adds items to the web.config file, and puts the Microsoft.Web.Preview.dll in the bin directory.
The CTP continues to be re-released with additional feature investigations. Some of these features make it into the core supported releases with changes that are driven by those who download it, try it, and provide feedback in the forums at http://go.microsoft.com/fwlink/?LinkID=77294.
One key distinction between the ASP.NET AJAX release and the CTP is that the CTP is not installed in the GAC. Instead, it goes in the /bin directory of your application. Any feature that needs full trust must get it by virtue of your application running in full trust. So far, the number of features limited by the need for full trust has been very small, but it is something to check in the release notes if you are deploying to a hosted environment where you run under partial trust.