ASP+ Deployment
If you have ever tried to deploy a complex ASP application that utilizes COM objects into a shared multi-application environment, you know how difficult that really is. ASP+ has simplified the deployment model to just copying all files which comprise an application into the appropriate directory. No registration of objects or restarting of the application is required. All parts of an ASP+ application can be deployed in this fashion, including pages, Web Services, compiled components (DLL), and even some configuration data, as shown in the next section.
For compiled components there is now a special directory under each application root, called "/bin." Any components placed in this directory are automatically made available for use within that application. Note that they are only made available to that specific application. This gives you true application isolation—that is, each application on the server could be running a slightly different version of the component with no effect on other applications! This is a huge win for developers who host multiple instances of a site on one machine, such as a development environment, a test environment, and a staging environment, each with different component versions.
ASP+ no longer locks DLLs to prevent you from updating them. You can just copy the new DLL on top of the old one. ASP+ automatically detects the change and migrates to the new version. Currently executing requests are drained off the old version and new requests are directed to the new version. You no longer have to reboot or restart the application. To uninstall, you simply delete any piece of the application and be done with it—no components to unregister, no Windows Registry entries to change.
ASP+ Configuration
If ASP+ didn't change its configuration model at least a little, the deployment story above wouldn't be so great. Today most configuration changes for an ASP application are ferreted away in the metabase. The metabase is not easily replicable and changes to it are scripted typically to roll them out in a consistent fashion across a cluster. ASP+ moves many of its configuration settings into the config.web file. This is an XML document that allows for hierarchical storage of configuration settings. Here's an example:
<configuration>
</configuration>
This format is as easily read and written by people as it is by machines. The fact that it lives in the file system further extends the xcopy deployment I mentioned in the preceding section. Developers can place their own configuration information in this file, in addition to ASP+ configuration information. Things like DSNs and application constants are all good candidates. The config.web file is also inheritable; the master config.web file sets all general settings and other config.web files in each application root-inherit those settings. The local config.web file can also override global settings, providing you with a very flexible configuration model.
ASP+ Session State
One of the biggest limitations of session state in the current implementation of ASP has thankfully been eliminated. ASP+ now supports moving session not only out of process but also out of machine. This means that you can create a dedicated state server that handles state for multiple boxes in a Web farm. Although there's obviously a performance hit for moving session out of process, the advantages are enormous. Session state can now survive application restarts as well as machine restarts. The new out-of-process session state provider runs as a service that is accessed over TCP/IP on a port and host that you configure. This allows it to operate through firewalls, over routed connections, etc.
A second session state provider has also been implemented, which uses SQL Server as a durable data store. This allows session data to survive the restart of the session server, albeit at a much higher cost to performance.
One of the main limitations of session state has been its requirement of cookies to reconnect users to their state store on the server. ASP+ now offers a cookieless state, which works by munging all relative URLs in your application and including the information normally stored in the cookie in the URL. This cookieless state and out-of-process session state should effectively eliminate most of your reasons for not using session state.
ASP+ Caching
Developers have known for years that caching is an area where big performance wins can be gained. Several vendors—including Post Point Software and WebGecko Software—have caching solutions today for ASP 3.0.
ASP+, however, has three forms of caching built in. The first is page output caching. This provides an in-memory cache of the output from an .aspx page. Cached copies are created for each combination of URLs as well as various headers that you specify. One limitation is that HTTP Posts are not supported, only HTTP Gets.
The second type of caching is fragment caching, which allows subsections of a page to be cached while other parts of the page remain dynamic.
Finally, ASP+ makes an extensible cache API available to developers for caching any arbitrary objects. This cache API includes expiration policies as well as file-change notifications that allow developers to increase performance significantly. Note that, unlike the session object, the extensible cache is not per user; instead, it retains application scope. It is perfectly acceptable now to store objects in the cache created with VB. Visual Studio .NET has added the Both threading model to VB, eliminating the thread affinity problems normally associated with storing objects in the session or application state.
ASP+ Authentication/Authorization
ASP+ supports five built-in authentication schemes: Basic, Kerberos, NTLM, Microsoft Passport, and those based on custom forms. The Basic, Kerberos, and NTLM authentication methods are largely unchanged from IIS5. The Microsoft Passport authentication allows for integration with the Microsoft Passport login/personalization service. Many people out there, myself included, primarily purchased Site Server 3.0 for its Personalization and Membership feature. It provided a powerful system for doing forms-based authentication and authorization against an LDAP directory that scaled much better than the NT domain model. ASP+ has stolen much of Site Server's thunder with the addition of forms-based cookie authentication. This feature allows you to create your own custom login screen using HTML and create your own custom credential checks against a database, Microsoft Exchange, or whatever you desire.
ASP+ also introduces the concept of roles. Roles map users into logical groups: accounting, human resources, IS, etc. Permissions can be assigned based on these roles, providing a nice abstraction for developers from the administration of the system. Developers can perform runtime role checks in code similar to what MTS provides using a syntax like this:
User.IsInRole("Accounting")
ASP+ provides for URL-based security. No longer are you relegated to using the NT-based ACL system for placing permissions on your site. Now you can specify in the config.web file which users or roles are allowed to access various paths in your application regardless of the ACLs in the file system. More on this in future articles.
ASP+ Debugging
Now that ASP+ is based on the new .NET runtime, the debugging story has gotten much better. With a single debugger you can debug your pages, jump into an object, hop back into the page, and so on. You no longer need to load multiple debuggers. The debugger that ships with the SDK includes a single stack trace across the pages, components, and all running code.
ASP+ now supports page tracing. You will appreciate the utility of this feature if you have ever debugged using Response.Write. A page trace collects all the request object details—including the server control tree, server variables, headers, cookies, and form/query string parameters—and places them in a nicely formatted table at the bottom of each page. It also inserts a log of all events raised on the page, along with accurate timings. You can add your own messages into this log using Trace.Write:
Trace.Write("Errors", "Help!")
This expression evaluates to a null operation when page tracing is turned off. No more messy Response.Write() calls to forget to remove! If you don't want the page trace to appear on the page, there is an option for tracing pages globally. By going to http://localhost/application/trace.axd, you can get a list of all pages recently run by the system and view their trace details—not something you would normally want to run in production but great to turn on temporarily to trace down an especially pernicious problem.
ASP+ Scalability and Availability
ASP+ has been designed to provide the utmost in scalability and availability. It handles both user and system code failures automatically. It also recovers automatically from access violations, memory leaks, and deadlocks. ASP+ does this by setting the maximum requests queued or memory size in the config.web file. When the ASP+ process hits these limits a new instance of the application is started, requests are directed at it, and the old process is drained and finally shut down. In addition, ASP+ supports the concept of preemptively restarting applications. This gets rid of the need to restart the box once a week just to make sure your application stays up. ASP+ can restart the ASP+ process based on the number of requests served or the amount of time the application has been running. Both of these settings are also in the config.web file.
As you can see, ASP+ is a major upgrade that provides a boatload of new features for developers. Over the next few weeks I plan to delve into each of the areas mentioned above more deeply and help you get started on your way to being productive with ASP+.
Chris Kinsman is Vice President of Technology at DevX.com. He is reponsible for the site architecture, development, and day-to-day maintenance of the DevX network of sites.
