In-Depth
Improve Productivity With ASP.NET 2.0
The latest version of ASP.NET incorporates major structural changes and includes everything from new controls to new subsystems. Everything's aimed at making you more productive.
Technology Toolbox: ASP.NET 2.0
ASP.NET 2.0 includes everything from new controls to new subsystems, and it incorporates major structural changes that change the way that you'll use ASP.NET. ASP.NET 2.0 features new subsystems that handle common problems (including identifying the user and managing user preferences), convert typical Web development tasks into drag-and-drop controls, provide a more flexible compilation model with simpler deployment, and deliver databinding controls that simplify data access and retrieval. All of these changes have one effect: to make you more productive. You want this upgrade.
Think "more" rather than "different." Much of what you know about using ASP.NET development remains the same—you just have a lot more to learn. But don't panic—Visual Studio 2005 includes a wizard that should convert your ASP.NET 1.* Web sites to ASP.NET 2.0. It won't be without pain, but most sites should convert with a minimum of programmer intervention.
However, you don't have to upgrade your existing Web sites to ASP.NET 2.0 if you don't want to. After you install .NET 2.0 on your Web server, you'll discover that the ASP.NET tab on your Web site's property pages lets you specify which version of ASP.NET you want to use with your site. Your existing ASP.NET applications can coexist with ASP.NET 2.0 (or be upgraded with a minimum of fuss), so you should be thinking about when, not if, you want to upgrade (see Figure 1). And after you upgrade, you can start thinking about what you'll do next (see the sidebar, "What's Next for ASP.NET?").
The Visual Studio 2005 toolbox features quite a few more controls than the previous version. Templated controls are more common, such as the Wizard control, which allows you to build a multistep process as a series of templates held in a single control on a single page. Other controls plug holes that existed in ASP.NET 1.*. The Substitution control, for instance, solves a significant problem with caching pages by allowing you to specify a part of a cached page that is to be updated each time the page is requested. In ASP.NET 1.1, only the page displayed in the browser could be requested when the user on clicked a Submit button. In ASP.NET 2.0, cross-page posting allows you to add a button to your page that posts to any page in your site. On the new page, your code can retrieve information from the page that triggered the request, providing a simple solution for implementing help or search pages (or any other page that should be accessible from multiple pages on the site).
However, the real stories in ASP.NET 2.0 are in the structural changes to ASP.NET and in the new ASP.NET subsystems.
Adapt to Structural Changes
Solution Explorer exposes the first set of structural differences that you're going to have to adapt to. The key change is easy to miss: The entry at the top of the listing for the Web site is a file path rather than the name of a project. Visual Studio 2005 considers all the files in a directory part of a Web site and doesn't require a project file to list a project's resources. All the other information formerly stored in the project file has migrated to the Web.Config file.
It's also easy to see that the file structure for your Web site is more complicated. Instead of the single required /bin folder for holding your application, there are a variety of specialized folders for holding your application's components. The App_Data folder holds database files (including SQL Server MDF files), and the App_Code folder holds both the source code for any class files that make up your project and the code-behind files for your ASMX Web service pages. You don't have to use these folders if you don't want to, but they will make your life easier. Adding a database file to the App_Data folder adds the database to Server Explorer automatically. Deploying your application is also easier: Picking Web Site | Copy Web Site copies the whole Web site folder, automatically moving the databases in App_Data and the class files in App_Code to the target Web site.
Treating all the files in a directory as the Web site makes debugging much simpler. When you press the F5 button to test your site, Visual Studio 2005 starts up its own development Web server, which you can access only from a browser started from Visual Studio 2005 (see Figure 2). The server stays up and running in the system tray as long as you continue to work with your project, but the server can only be used to access your development directory. You don't need IIS to test your site any more, and organizations that were concerned about installing IIS on developers' computers should find their fears allayed by the development server.
After debugging comes deployment, which brings us to the next major change in your ASP.NET life: the compilation and deployment model. The first evidence of the new model appears when you open your code-behind file. You'll notice that the file is smaller than it was in ASP.NET 1.*, where the file held both your code and the automatic code generated by Visual Studio. The code-behind file in ASP.NET 2.0 is a partial class and holds only the code that you generate. The code generated by Visual Studio 2005 still exists, but is kept in another partial class file in separate directory. When you compile or deploy your application, Visual Studio assembles a complete class out of the page's partial classes.
The key word in deployment is "flexibility." By default, Visual Studio 2005 deploys your application as source code. Your code is compiled on the target Web site when a page is requested. This gives you the ability to update your site in place simply by opening your code-behind or ASPX files in Notepad and rewriting the contents. If you're concerned about the performance hit that compiling your code on demand will incur, you can compile your application into a cached set of executables by running the Precompile.axd utility after you've deployed your site.
If, on the other hand, you don't want source code on your Web site (because it allows anyone who gains access to your site to rewrite your application), you'll want to use the Build | Publish Web Site option to deploy your application. The Publish Web Site dialog compiles your code into DLLs as part of deploying the site. You can choose to compile each page's code-behind file into a separate DLL so that you can update the site one page at a time by replacing the DLLs for individual pages.
Simplify Common Tasks
The ASP.NET team not only restructured your ASP.NET application, but they also looked at the common tasks developers were coding on every site. For instance, most developers kept their connection strings in the appSettings section of the Web.Config file. ASP.NET 2.0 supports this by adding a connectionStrings section to the Web.Config file that you can access through the WebConfigurationManager object in your code. If you're worried about unauthorized users accessing your Web.Config file, you can encrypt the strings in the file and they will be decrypted automatically when accessed from your code.
Many ASP.NET 1.* developers took advantage of FormsAuthentication to control access to their site. However, it was still the developers' responsibility to create the login pages, authenticate the user, and differentiate between content for logged-in and anonymous (guest) users. ASP.NET 2.0 wraps all of these tasks up into an authentication subsystem, which includes a set of controls that identify the user, provide feedback on login status, and customize output for logged-in and anonymous users. All of this is tied into an automatically generated SQL Server database (called ASPNETMDF and placed in the App_Data folder) that holds usernames and passwords. If you're not happy with the default authentication process, you can add your own code to the Login control's events to implement your own authentication scheme (see Figure 3).
You can write your own code to add users to your user database. However, the ASP.NET Web Configuration tool (available from Visual Studio 2005's Web site menu) provides a browser-based interface that allows you to set up the users that your site needs (see Figure 4).
The membership system builds on top of the login controls. Membership allows developers to define new information about a user and save it automatically. The collection of information related to a specific user is the user's profile. As soon as a user is authenticated, ASP.NET loads the Profile object with the user's information and you can read or update the data from code.
Users' customization isn't limited to whatever information ends up in their profiles. By adding WebPartZones to your page, you can allow users to customize the structure of their page while viewing the page in the browser. Depending on the combination of WebParts on the page, users can minimize controls, remove controls from a page, add new controls, move controls from one WebPartZone to another, or set properties on the control. The membership subsystem makes sure users see their customized page the next time they log in (see Figure 5).
You're not obligated to use the login system in order to use the membership system and implement customization. When you add the anonymousIdentification tag to your site's Web.Config file, ASP.NET generates a cookie that uniquely identifies the user and connects him to his profile. Together, though, the membership and authentication subsystems provide a complete, packaged solution for common user-related activities.
Snap in Your Own Solutions
The problem with packaged solutions is integrating them with the resources already in place. Most sites already have a user database and aren't anxious to either convert to a new database or maintain user information in two locations. Another structural change—the move to a provider-based architecture—gives you the flexibility to modify the packaged solutions to meet your situation.
The Authentication subsystem provides an example of how the provider architecture works. By adding tags to the Web.Config file, you can specify which objects are to be used for authentication (ASP.NET comes with authentication objects that use SQL Server, Access, and Active Directory). In addition, you can configure a provider with additional entries in the Web.Config file. In the Authentication subsystem, you can specify a single authentication database to be used for all Web sites and specify that the authentication tables are to be created in one of your existing databases. If configuring existing authentication objects doesn't meet your needs, you can write your own provider object and incorporate it into the Authentication subsystem.
Providers deliver the base for customizing ASP.NET 2.0. Many systems provide multiple points for customization in addition to configuring or building providers. The Membership system, for instance, allows you to create your own object to process profile information. When an application sets or reads user-related data, your custom profile object is invoked automatically to perform any additional processing that you want to insert into the process. All you have to do is write your object and insert a few tags into your site's Web.Config file.
Most developers use Cascading Style Sheets (CSS) to apply a common look and feel to their site. However, CSS wasn't designed to supply a common layout for pages or to replicate common controls across all the pages in a site. In addition, CSS limits developers to style attributes on HTML tags rather than the properties on ASP.NET controls. ASP.NET 2.0 provides two tools to make your life easier: master pages and themes.
Master pages allow you to build a common visual foundation for the other pages on your site (see Figure 6). Any elements that you want to be on every page can be added to the master page. In addition, you can add ContentPlaceHolders that specify where the child pages based on the master page can place their unique content. You can add also properties and methods to your master page that you can access from the child pages, allowing you to encapsulate common code for your site into the master page.
There is a lot of flexibility in using master pages—more flexibility than Visual Studio 2005 will support. For instance, if your Web site consists of several subsites, you might be tempted to build a master page for your site as a whole and then create individual master pages for each subsite. ASP.NET will let you nest the subsite master pages within your site's master page, but you're going to have to give up using Visual Studio 2005's Design view and resign yourself to working with your tags directly in Source view. Similarly, you can specify the master page for your site in the Web.Config file, providing a single point of control for your site's layout. However, if you do, you won't be able to use Design view when building your site's pages.
You might want to add your site's menuing system to a master page (see Figure 7). ASP.NET provides two different menus for you to use: a pop-out/dropdown menu and a treeview. Both of these controls build their menus based on data in an XML site map file containing a hierarchical listing of the site's pages. The structure in the site map doesn't have to correspond to the actual folder hierarchy for your site—in fact, the site map insulates your users' view of the site's structure (the menu) from any physical changes you make to the site's folder structure. You can also add the SiteMapPath control, which uses the site map file at run time to display "breadcrumbs"—the current page's position in the site's menu structure. The controls do have one significant limitation: In order to support the SiteMapPath control, no page can appear twice in the site map. You can only provide your users with a single navigation path to any page.
However, layout and repeated controls are only part of ensuring a standard look and feel for your site. ASP.NET 2.0 continues to support CSS and adds themes as a way for you to manage the appearance of your ASP.NET controls. Themes consist of both HTML CSS files, as well as files containing ASP.NET skins. You can specify values in a skin both for HTML attributes and ASP.NET properties. You can tie your skin to a specific type of ASP.NET control or even to a specific control. What's missing in Visual Studio 2005 is a skin designer to match the CSS designer (which is unchanged from ASP.NET 1.1).
Meet a New Databinding Paradigm
Databinding is another area that has seen major changes. In ASP.NET 1.*, databinding was a minimal implementation: Developers had to write code to retrieve their data and to perform any updates, often working directly with the underlying ADO.NET objects. The major databinding control, the DataGrid, was too inflexible for use out of the box, and most developers had to write a series of hacks for the DataGrid to get it to do what they wanted.
ASP.NET 2.0 databinding, on the other hand, starts with the DataSource controls that encapsulate the ADO.NET controls that retrieve data. You can switch the DataSource controls from using DataSets (which give you the ability to manipulate your data after it's been retrieved) to using DataReaders (which reduce memory consumption) with a single property setting.
You can still databind individual controls, but Visual Studio 2005 doesn't support this directly. You must switch to Source view and type in the code yourself. Instead, ASP.NET 2.0 comes with three controls that act as containers for databound controls: DetailsView, GridView, and FormView.
DetailsView is the simplest control to use. Simply attach it to a DataSource, and the control generates a label and textbox for every field to display a single record at a time. You have a wide variety of customization options that you can take advantage of, including using templates to replace DetailsView's default controls. GridView is equally easy to use, but displays multiple rows instead of a single row—again, with numerous customization options. Of the three, FormView is the most flexible control. FormView is a container for any other control that you want to bind to a field in a DataSource (see Figure 8).
Most of the limitations that were present in the databinding controls in ASP.NET 1.* are gone. All three of the controls support paging, though only GridView supports sorting data. Working with the DataSource they are bound to, the controls take care of retrieving the data from the database, moving the data to the page, and, when the data is returned to the server, performing any required updates, deletes, or insertions. You can bind the parameters in your SQL statements or stored procedures in your DataSources to any of a variety of objects (Session variables, controls on the form, QueryString values, and data in the user's profile). When you do, the DataSource will even take care of picking up the values to use when retrieving data.
However, if you retrieve data from more than a single table, taking advantage of the DataSources' ability to update data automatically is awkward at best. Fortunately, all of the databinding controls have a rich event model that lets you insert your own update code into the processing cycle.
From adding new controls to featuring a new compilation model, ASP.NET 2.0 provides you with a much larger toolbox. You'll find that the new toolkit gives you more flexibility, solves common Web-application problems more simply, and—more than anything else—makes you a more productive developer.