• Illustration: ASP.NET 2.0 Developer Architecture
• Illustration: Master Pages in ASP.NET 2.0
• Illustration: Tag Outlining in VS.NET Whidbey
• Illustration: Navigating Complex HTML Files in VS.NET Whidbey

ASP.NET is critical to developer adoption of Microsoft’s .NET Framework, and Web developers already using ASP.NET will find ASP.NET 2.0 to be a "no-brainer" upgrade, providing improved performance and manageability and substantially reducing the amount of custom code they must write. For developers using competing products or Microsoft’s Active Server Pages (ASP), the new features may prove tempting enough to entice them to finally take the plunge and move to .NET.

In addition to including new features that reduce the amount of code developers must write, ASP.NET 2.0 includes features such as support for membership tracking and personalization that were once the exclusive domain of products such as Commerce Server and SharePoint Portal Server (SPS). These new features may make it harder for IT organizations to justify the other products.

Although a beta release is not yet available, attendees of Microsoft’s Oct. 2003 Professional Developers’ Conference received prerelease copies of ASP.NET 2.0, which, along with the next release of Visual Studio .NET (VS.NET), is code-named Whidbey.

Simplified Development

Microsoft first introduced ASP.NET, the successor to ASP, in July 2000 as part of the initial rollout of VS.NET and the .NET Framework. Since that time, ASP.NET has been the driving force behind much of the initial adoption of the .NET Framework. Microsoft clearly hopes that developers already comfortable using the .NET Framework and languages such as C# and Visual Basic .NET (VB.NET) to build Web-based applications will naturally choose .NET when it comes time to rewrite middle-tier systems, deploy Web services, or build custom client applications.

ASP.NET 2.0 improves on its predecessor in several ways:

Building-block services provide basic functions that a wide range of applications can use. For example, ASP.NET 2.0 provides built-in support for managing membership information, such as user names and passwords, without requiring the developer to write any custom code.

A new provider architecture allows the new building blocks to operate against a variety of back-end data stores. For example, a well-defined membership API allows ASP.NET 2.0 applications to store their user information in a SQL Server database, Active Directory, or a custom store.

Page frameworks build on underlying building blocks to provide higher-level application services, such as a new framework for building portals and components that help build navigation features on Web sites.

New controls build on the new services and application features in ASP.NET 2.0.

(For an illustration of how building blocks, providers, page frameworks, and the new controls interact, see "ASP.NET 2.0 Developer Architecture".)

VS.NET improvements remove roadblocks that forced some Web developers to use more primitive tools, such as Notepad.

Manageability improvements give IT administrators script-based management interfaces and GUI tools that plug into the Microsoft Management Console (MMC).

Building Blocks and Providers

ASP.NET 2.0 introduces a set of building-block services that provide functionality likely to be needed by a broad range of applications. Developers can use building blocks to replace custom code in many cases. Some of these building-block services include the following:

Membership. Many Web sites require users to register in order to access information, and must therefore have systems to securely store and validate user names and passwords and to let users reset forgotten passwords. Previous versions of ASP.NET required developers to create the appropriate database schema as well as write code to manage those passwords. ASP.NET 2.0 automates the entire process with tools to define database schema and components that process log-on requests.

Personalization. ASP.NET 2.0 includes services for personalizing a Web site with common user information, such as first and last name, or with custom information, such as an associated shopping cart. It can even accumulate personalization information on an unauthenticated user, then associate that information with an authentication record when the user chooses to log on. E-commerce sites, for example, usually let users fill a shopping cart, then link that shopping cart to a user account when the user logs on to complete the transactions.

Database caching. Previous versions of ASP.NET included the ability to store recently retrieved database information in a local cache, improving performance by reducing unnecessary database queries. ASP.NET 2.0 improves this caching not only by allowing developers to specify the length of time the results should remain in the cache but also by automatically invalidating the cache if the underlying database changes. The granularity of this feature depends on the database being used. SQL Server 7 and 2000 support table-level invalidation (when data in a table changes, all cache entries from that table are invalidated); the next version of SQL Server, code-named Yukon, will support row-level invalidation.

While these building-block services would be useful by themselves, ASP.NET 2.0 gains significant flexibility by adopting a "provider" architecture that separates higher-level components and user code from lower-level components, such as data storage. For example, ASP.NET 2.0’s membership service is separated from the underlying database by a Membership Provider that allows the developer to choose from among several supported databases (including SQL Server, Access, and Active Directory) or write their own provider to connect to a custom store.

In addition, ASP.NET 2.0 uses a provider model for retrieving pages. The prerelease version supports only the file system, but the final version will be able to retrieve pages from a database, which should ease integration with content management systems.

To help others develop custom providers, Microsoft includes the complete source code for the built-in providers.

Page Frameworks Provide Application Services

Page frameworks use building blocks to provide higher-level application services, such as customization and personalization.

Master pages. Most Web sites strive to provide a consistent look across all pages. ASP.NET 2.0 allows developers to define master pages, which specify the general layout of a set of pages, and then create child pages based on the master. The developer can then update the look of every page on the site by editing a single master. Although some development tools also provide this capability, editing a master usually requires every file on the site to be regenerated and republished. ASP.NET 2.0, on the other hand, requires only the single master file to be republished. (For a visual example of master/child pages, see "Master Pages in ASP.NET 2.0".)

Themes and skins. ASP.NET 2.0 allows developers to create Web sites that can be personalized for each user with themes and skins. A skin is a set of properties that can be applied to a control. For example, a skin might enforce consistent colors for all tables. A theme is a collection of skins, along with additional formatting information such as images and cascading style sheets (CSS). Deployment of themes and skins is simple—each theme is a subdirectory in the Themes directory. By combining themes and skins with personalization features, developers can allow users to personalize the appearance of a Web site.

Adaptive interface. Previous versions of ASP.NET supported mobile devices, such as Microsoft’s Pocket PC and Smartphone platforms, through a set of specialized mobile controls that could adapt user interface (UI) elements for smaller screens. (For more information, see "ASP.NET Supports Mobile Browsers" on page 17 of the Mar. 2003 Update.) ASP.NET 2.0 integrates those capabilities into the standard set of controls. Existing applications that rely on the earlier mobile controls (or the even earlier Microsoft Mobile Internet Toolkit) will continue to run on ASP.NET 2.0.

Integrated Web Parts. Previous versions of ASP.NET treated Web Parts—modular components designed for use in portals or collaboration products, such as Windows SharePoint Services, or SPS—as special components, making them more difficult to author. With ASP.NET 2.0, any control can be a Web Part, which should make it much simpler for developers to build them. However, although ASP.NET 2.0 is backward-compatible with existing .NET-based Web Parts, it is not yet certain whether Web Parts created in ASP.NET 2.0 will be compatible with other Web Parts hosts, such as SPS.

New Controls

ASP.NET 2.0 includes about 50 new controls, many of which build on the new services and application features in ASP.NET 2.0. For example, a developer can create a log-on page by dragging and dropping a new Login control to the page. The control automatically uses the new membership services to allow users to register themselves, log on, and reset their passwords. In addition, the control is designed to accept themes and skins and to work with the adaptive UI system to render itself appropriately on devices such as cell phones.

ASP.NET 2.0 also includes several new controls that read the site hierarchy (the links among pages on a Web site) from a set of XML files to automatically provide navigation links. (Developers can author these XML files manually, generate them with Visual Studio, or populate them with information from a database such as that used by a content management system.) A Tree View control reads the site navigation information and displays the information in a tree whereas the Bread Crumbs control displays the information in a more condensed format. The site for Directions on Microsoft, for example, might use bread crumbs that, for this article, show "Home > Members > Update > Feb. 2004," with each element being a clickable link.

Finally, ASP.NET 2.0 combines its Web Parts controls with the built-in membership and personalization system, making it almost trivial for developers to create fully featured portals that allow users to customize their own pages from a set of standard parts. In fact, although ASP.NET 2.0 does not have the content indexing and searching features of SPS, it provides a much easier development environment. Future versions of SPS, however, will be based on ASP.NET 2.0 and will undoubtedly gain the same development features offered by ASP.NET 2.0.

Developer Tools

ASP.NET has proven very popular for Web application development, but many developers have opted not to use VS.NET. Although VS.NET includes many features designed to make ASP.NET development even easier, many Web-savvy developers found VS.NET to be overly complicated. For example, the current version of VS.NET requires developers to create solution files that contain projects (such as a Web application), and to build and deploy their solution before they can see the result of any changes. Many Web developers, however, prefer to edit raw ASP.NET files directly (using a simple text editor) so they can immediately see those changes in a Web browser. Even though ASP.NET has always supported the text-editing approach to development, VS.NET did not. To meet the needs of Web developers who wanted to use ASP.NET but found VS.NET too complex, Microsoft went so far as to produce and make freely available a much smaller ASP.NET development tool known as ASP.NET Web Matrix.

The next release of VS.NET, however, features some improvements that Microsoft hopes will win over ASP.NET developers who have yet to adopt VS.NET. These improvements fall into several categories:

Directory-based projects. VS.NET Whidbey no longer requires developers to create solution files for their Web projects, eliminating one of the most cumbersome and difficult-to-understand aspects of VS.NET. Instead, they can simply point VS.NET Whidbey at a directory containing a Web project and begin editing. In addition, VS.NET Whidbey no longer requires that FrontPage Server Extensions be installed on the Web server.

Support for inline code. ASP.NET has always allowed developers to use either "code-behind" development (in which the source code for the application is stored in a separate file from the Web page markup code) or "inline" development (in which the source code and the markup code are contained in the same file). VS.NET, however, supported the code-behind model only. Many Web developers prefer the inline model because it reduces the number of files that must be deployed and maintained—in fact, support for inline code was one of the main attractions of the ASP.NET Web Matrix tool. With the Whidbey release of VS.NET, although code-behind remains the default, inline code is fully supported, allowing developers to use whichever model they wish.

Flexible HTML formatting. Although VS.NET includes built-in WYSIWYG (visual) HTML editing, many developers opt to write HTML by hand or use one of the plethora of third-party tools. VS.NET Whidbey aims to better support those users in two ways: first, it will not alter any existing HTML; second, it includes an almost mind-boggling number of options to control the formatting of any HTML it generates. The combination of these features should enable Web developers to combine VS.NET Whidbey with other tools or to hand-author HTML with much less difficulty than before.

Tag outlining and the Tag Navigator. To help Web developers who prefer to edit their HTML as text (instead of using a visual designer), VS.NET Whidbey includes two new features that make navigating large HTML files easier. Tag outlining allows developers to collapse large regions of HTML (such as large tables) down to a single line of text. (See the illustration "Tag Outlining in VS.NET Whidbey".) The Tag Navigator is a small region at the bottom of the HTML editor window that identifies the nested set of tags containing the current text insertion point. This is particularly useful when editing tags that have complex nesting relationships, such as tables that contain rows that contain cells. (For an illustration, see "Navigating Complex HTML Files in VS.NET Whidbey".)

Built-in Web server. VS.NET Whidbey includes a built-in Web server, eliminating the need for developers to install Internet Information Services (IIS) to develop, test, and debug ASP.NET applications. Furthermore, the built-in Web server will accept local requests only and is automatically shut down when VS.NET is closed, eliminating the potential security vulnerability associated with having an active Web server on each developer’s system. The built-in Web server should also prove useful for developers looking to run their development tools with non-administrative user accounts, although there are still many other limitations and workarounds developers face when trying to do that. However, the built-in Web server is sufficiently different from IIS that developers must still test their applications on a server running IIS before deploying them.

Hosting and Management

In addition to streamlined development and better tools support, ASP.NET 2.0 includes several improvements to its hosting and management capabilities:

Configuration. ASP.NET is primarily configured by a set of XML files. Configuring prior versions of ASP.NET largely meant manually editing these files. ASP.NET 2.0 can be controlled through a set of command-line scripts or managed by a new MMC snap-in that is integrated with the IIS administration tool. These new tools should make it easier for IT administrators to configure ASP.NET (either by automated scripts or MMC) without having to manually edit configuration files. In addition, a set of Windows Management Instrumentation (WMI) providers allow system administrators to view and change important configuration and performance information via WMI-compatible tools.

64-bit support. ASP.NET 2.0 supports both the Intel and AMD 64-bit architectures. Although few applications are likely to require the additional memory capabilities provided by 64-bit processors, organizations looking to consolidate large numbers of ASP.NET applications onto a single server may find the new support helpful.

Transport-agnostic. Prior versions of ASP.NET were dependent on the Hypertext Transfer Protocol (HTTP), but ASP.NET 2.0 is transport-neutral and can be configured to respond to TCP (or other protocol) requests. Even though this provides little immediate benefit, Microsoft hopes that developers will eventually be able to combine the application-level features of ASP.NET 2.0 (such as membership tracking) with the transport-independent messaging and Web services features of "Indigo"—the messaging system that is part of the next major version of Windows, code-named Longhorn.

Impact on Portal, Content Management Unclear

The new features of ASP.NET 2.0 make an already popular Web application platform even more compelling. Likewise, the improvements to VS.NET Whidbey seem destined to be very popular with developers.

But as often happens when new features are added to a base platform, products that build upon the platform will face pressure to move upstream in order to justify themselves to IT planners. This is as true for Microsoft’s own Content Management Server and SharePoint Portal Server as it is for competing products.

Resources

For more information on ASP.NET 2.0, see the ASP.NET Developer Center at msdn.microsoft.com/asp.net.

An active community Web site devoted to ASP.NET can be found at www.asp.net. Specific information on the new release of ASP.NET can be found at www.asp.net/whidbey.

Addison-Wesley has published a book on the new version of ASP.NET entitled A First Look at ASP.NET v. 2.0, ISBN 0-321-22896-0.