Creating Web Sites with ASP.NET Whidbey

ASP.NET Whidbey adds a huge number of productivity features and enhancements.

Although it's still early in the development process, Paul and Ken dig in and start playing with some of the new features, passing along what they've found.

We remember clearly the time period before ASP.NET 1.0 shipped. While building applications using ASP, we said over and over "I sure wish we could use this stuff right now," referring to ASP.NET. Having seen a preview version of ASP.NET Whidbey that's included as part of the Whidbey release of Visual Studio .NET, we're doing it again. We really want to use this new technology right now. Of course, the product is still in its early stages, so anything and everything can still change, but it certainly appears that the number of features added for ASP.NET Whidbey rivals the number of features added for the original release. That is, ASP.NET Whidbey looks very cool.

We can hardly wait to get started building applications using all these new toys.

In this article, we'll point out some of the changes to ASP.NET that are going to make it much easier to develop Web sites in a fraction of the time it takes now. (Note that this article was written in September 2003, using the Whidbey Alpha Milestone 2 release. By the time you read this, a newer version may be available with more and/or different features.)

Creating a New Web Application

The changes start when you first attempt to create a new Web project. If you select File and then New Project, you won't find an option to create a Web project. Instead, in the current version of Whidbey, create a new Web project by selecting File and then New Web Site. Figure 1 shows the New Web Site dialog box.

Unlike the project template you might have used previously, the Whidbey Web project templates actually create useful starting points for applications. The following sections show off some of the features of each of the new templates. You'll be amazed at how much time these templates can save you, when you're getting started with a new project. (Be aware that these templates use some of the new ASP.NET server controls?we'll discuss those later in the article.)

Note one big change in this version of ASP.NET: new Web applications don't create new IIS virtual roots. That is, ASP.NET Web applications are hosted in standard folders. That's why the dialog box in Figure 1 looks so simple?there's no issue here dealing with Web servers or virtual roots. Your project goes into a standard file system folder.

The ASP.NET Web Service template and Empty Web Site templates are much the same as in the previous version, so we won't discuss them here. The following sections describe each of the other Web site templates.

ASP.NET Web Site

Choose the ASP.NET Web Site template if you want to create your own custom Web site from scratch. This template supplies you with a blank Default.aspx page, and nothing more. You'll need to add all the other pages yourself. Other templates, as you'll see, provide a much better starting place for most Web applications. This template also includes a folder named Data?as you'll see, this folder becomes the location where you'll put various data-related objects as part of your site.

Note that when you create a new Web project in Whidbey, the project always contains a page named default.aspx. How many times did you battle with this naming issue in earlier versions of Visual Studio .NET? This small change is indicative of the kinds of fixes made by the ASP.NET team?they saw the types of issues developers faced when creating new sites, and worked to minimize the hassles. This was a small one, but its fix is certainly appreciated.

ASP.NET Internet Site

The ASP.NET Internet Site template makes a great starting place for an Internet site with public pages, and possibly a secure area for members. This template provides a complete site, with menus, login pages, secure folders, and a master page that you can modify to suit your own needs. (More on master pages later, but these pages allow you to create a "base page" into which you can insert your own content. This allows your site to have a consistent look and feel with very little effort.) This site also supplies pages for articles, and a picture gallery for members. If you've used the ASP.NET Community Starter Kit, you've got the basic idea.

Having seen a preview version of ASP.NET 2.0 that's included as part of the Whidbey release of Visual Studio .NET, we're saying it again: We really want to use this new technology right now.

Figure 2 shows the default page built for you when you use the ASP.NET Internet Site template. This page shows off many of the new features of ASP.NET Whidbey. Most important, this page uses the new Master Page feature to create the basic look that's shared across all the pages within the site, and provides the content on the left and top portions of the page. The master page allows you to create a common look and feel for each page, but allows each page to have its own distinct content area.

The master page created by the Internet Site template includes a LoginView control at the upper right of the page that shows three hyperlinks: login, register, and contact. Once you log in, these three hyperlinks change automatically to logout, profile, and contact. In other words, the LoginView control manages the links based on the authentication state of the logged in user, so you don't have to do the work.

On the sample page, you'll also find a new SiteMapPath control that shows you how you got to your current location within the site. On the default page, the control just displays Home, but if you click on the Articles hyperlink on the left of the screen, then choose Article 1 from the tree view, you will see this control's text change to display Home > Articles > Article 1.

The data-bound TreeView control used for navigation on the left side of this page gets its data from an XML file. This special XML file, named app.sitemap, contains the data for navigating your site. You associate the app.sitemap file with a SiteMapDataSource control, and this SiteMapDataSource then becomes the data source for this TreeView control.

ASP.NET Intranet Site

Selecting the ASP.NET Intranet Site template creates a site that acts as a corporate portal. In addition to all the other features supplied by this page, as shown in Figure 3, the Intranet Site template supports personalization?you can click the Personalize This Page link, and then click and drag Web Parts around the page as shown in Figure 4. The new locations are saved for you, and when you next view the same page, the parts display as you last saved them. (This feature requires Microsoft Internet Explorer 5.5 or later.) The master page in this template site contains a LoginName control in the upper right corner of the page (taking advantage of Windows authentication to log in users), and a DataList control that displays the site map data from the DataSetDataSource control on the left side of the page. (This brings up another new feature?you can bind a DataSetDataSource control to an XML file directly. In that way, this DataList control retrieves data from an XML file, bound to the DataSetDataSource control that creates a DataSet based on data in the XML file.)

To create a Web Part, you simply create a user control and then add the control into a WebPartZone control. The WebPartZone control acts as a container for your user control, making it editable, customizable and moveable within the confines of any of the Web Part zones on the page. You'll learn more about creating Web Parts later in this article.

What Happened To IIS?

It's clear, given the examples so far, that Visual Studio .NET Whidbey makes it a lot easier to create and manage Web projects on your development computer. It appears that some magic is going on?you're getting Web sites created without the hassle of creating virtual directories! If you've ever created lots of sample sites on your development computer and then had the problem of cleaning up your IIS folder, deleting the Web cache folder, and making sure that you had a virtual root set up for every project you retrieved from other developers, you'll rejoice at the concept of not needing to involve IIS in your Web development. What's going on, then? How can you create Web sites and run them without needing to create virtual directories?

You'll rejoice at the concept of not needing to involve IIS in your Web development.

If you create a Web site using any of the first three templates and then you run the project, you will notice an icon and balloon appearing in the lower right hand corner of your screen, like Figure 5. This balloon indicates that you've started up the Visual Web Developer Web Server (similar to the Cassini server that ships as part of the Web Matrix product). This Web Server runs your site using a random port off of the localhost location, and doesn't require you to create a virtual directory from which to run your sites locally.

You might wonder why Microsoft chose to build a whole new Web server, rather than simply using IIS as they had in the past. There are several reasons why developing running IIS locally isn't a good idea:

• Working with and setting up virtual directories or new Web sites can be challenging for new developers.
• Not all operating systems provide a Web Server, and even Windows XP Professional doesn't install IIS by default.
• Running a Web server that broadcasts "Here I am, connect to me" (as does IIS) just invites hackers. That is, running IIS locally adds one more security risk, even behind a firewall. Why add this extra risk when it isn't necessary?
• Running IIS requires you to worry about keeping IIS locked down and installing the various IIS updates. Bypassing these requirements can lead to serious security flaws.
• Some corporations dictate a policy that won't allow you to run IIS locally. Although you can develop applications using IIS remotely, it's a lot easier having a local Web server.

Clearly, having a local Web server that isn't browseable remotely is an idea whose time has come!

The Visual Web Developer Web Server is installed by default when you install the Whidbey Alpha. Running a Web page within Visual Studio .NET Whidbey invokes the Web server on a randomly selected port for http://localhost. For example, if you are testing a page named Default.aspx and you browse to the page from within the development environment, you load the Visual Web Developer Web Server and the URL for the page might be something like this:

http://localhost:31544/Default.aspx

When you close the browser, the Visual Web Developer Web Server shuts down. The next time you test your page, the Web server restarts, and you will most likely browse to the page using a different port number. This constant starting and stopping of the Web server service combined with the assignment of random port numbers is just what security people like to see (or not see) when scanning their network. Also, this Web server does not broadcast past the local computer so no one knows you even have a Web server running.

Authentication Tasks Made Easier

Although managing authentication in ASP.NET has never been terribly difficult, it's always been something that every developer must handle individually, for each application. Realizing that this is a common requirement for every application, Microsoft has created a series of security-related controls in this new version. You'll certainly need to write less code, given the set of template-driven controls you'll find on the Security tab of the control toolbox. You'll be creating login pages with little or no code.

The new security-related controls utilize classes in the System.Web.Security namespace, and this namespace includes several new classes that make it easier to manage user, password, and role maintenance. These classes can use any data provider to store information about your users, passwords, and roles in just about any data store you wish.

In order to make it easier for developers to manage their sites' users, roles, and permissions, Microsoft includes a Web-based interface that handles all the details for you. Select Website and then ASP.NET Configuration to display a set of pages, as shown in Figure 6, to manage security. You can store your data in either SQL Server tables or Access/JET MDB files. Use this wizard to set up a new database with all of the necessary tables, and to add, edit, and delete users, roles, and permissions.

The Web Application Administration Wizard creates quite a few tables for you. Figure 7 shows a sample of these tables in an Access database for a sample application. (You'll find this database in the Data folder of an Intranet application you create using the ASP.NET project templates, as well.)

The Login control, shown in Figure 8, can be dropped onto any Web page. This control uses the .NET Framework's membership classes to check whether the user is authenticated?in other words, if the user is in the aspnet_Users table in your data store. If the user exists, and the password checks out, an authentication cookie is issued so ASP.NET knows the user has been authenticated. Like many of the new controls, the Login control supports templates, so that you can change just about every aspect of its appearance on the page. In Figure 8, we selected one of the supplied auto-formats.

The LoginView control automatically detects whether a user is authenticated, and displays an appropriate template. By default, you get two templates when you drag a LoginView control onto your Web page: AnonymousTemplate and LoggedInTemplate. You add any controls you wish to each template. For example, in the Internet site you saw earlier, the AnonymousTemplate has a hyperlink that displays login. This link was displayed when a user first entered the site. After the user logs into the site, the LoggedInTemplate is displayed and the hyperlink now displays logout. You may also add new templates, each associated with a user role. Using this technique, each role you define in the system may display different hyperlinks within the LoginView control. Figure 9 shows how you might edit the AnonymousTemplate template within the sample page's LoginView control.

The LoginStatus control (see Figure 10) can display either text or an image to represent the user's current logged-in status within an application. You can set up your site so that when users who aren't logged in click the LoginStatus control, they're redirected to the login page. Similarly, you can control the behavior when a logged-in user clicks the control. You can redirect to a logout page, refresh the current page, or redirect to the login page. No matter how you use this control, it can save you the effort of setting up the appropriate redirection and status indicators.

The LoginName control displays the value in the User.Identity.Name property on the current page. If this value isn't set (the current user is an anonymous user), nothing is displayed. This control will probably be used most often in the master page to display the name of the currently logged-in user, as in the sample shown in Figure 4.

The PasswordRecovery control makes it easy for you to provide a mechanism that allows users to recover their passwords. In most Web sites that require users to supply passwords, you'll need some way to allow users to request or reset their passwords. As you know, if you've used any commercial Web site, this can be done in any of several ways. You can request the user's ID, and then send the password. Another alternative is to ask the user to provide a question and answer at registration, and then prompt with the same question to validate the user's identity?if the user supplies the correct question and answer again, you can be fairly certain of the identity. Alternately, you can simply reset to a new strong password and send the user this new password. The user can then change the password at next login. Figure 11 and Figure 12 show two different views for the PasswordRecovery control. The third view (Answer view) allows you to control what the user sees after supplying an answer to the security question. As with other security-related controls, you can modify the templates associated with this control and completely alter the text and layout of the control.

Personalization Support on Web Pages

Lots of sites allow you to personalize content (one of us has spent far too many hours adding and modifying content on his MyYahoo! portal), but Microsoft kicked this technology up a notch by adding support for dragging and dropping Web Parts in its SharePoint products. By designing Web Parts using the interfaces required by SharePoint, developers can easily create intelligent, personalized "widgets" that can be displayed on Web pages.

In Visual Studio .NET Whidbey, it's easy to create the same sort of behavior. Once you've set up your page with appropriate Web Part container controls, you can move content areas around just by entering a special edit mode, then dragging and dropping areas of your Web page to a new location. You can customize titles of sections, as well.

For example, when you create a site using the ASP.NET Intranet Site template, the default.aspx page includes a hyperlink in the upper-right corner with the caption "Personalize this Page." Once you click that link, you are allowed to drag and drop the Web Parts from one location to another on the page. In addition, if you click the down arrow in the title area of one of the Web Parts, you can edit certain characteristics. For example, Figure 13 shows default.aspx with one of its parts being edited during personalization. Once you are done, click the End Personalization link to persist your changes. On subsequent visits to the page, your settings are retrieved and applied to the various Web Parts on the page.

Customizing Web Parts depends on the behavior of new ASP.NET server controls, such as the WebPartManager and WebPartZone controls. Customization of Web Parts is accomplished using the LayoutEditorPart and EditorZone controls. Check out the Personalization tab on the Toolbox window for more information on these controls.

Creating Your Own Web Part

It's easy to look at ASP.NET Web Parts and see them in action, but perhaps you'd like to create your own. Perhaps you're thinking they must be incredibly difficult to create. You'd be wrong?they're actually quite simple to create. Creating a Web Part can be as simple as dragging a user control into a WebPartZone control. To demonstrate how simple it can be to create a customizable Web Part, follow these steps.

1. Create an Intranet site, using the ASP.NET Intranet Site template.
2. Select Website and then Add New Item.
3. From the list of templates, select Web User Control, and set the name to MyCalendar.aspx.
4. Add an instance of the ASP.NET Calendar control to your new user control. (Select the Core tab on the Toolbox window to select the ASP.NET server controls.)
5. Save your changes.
6. Open the default.aspx page within the page editor, and select Design view by clicking on the Design tab at the bottom of the window.
7. Click on the right WebPartZone controls where you see other controls such as Daily Links and My Weather.
8. Click the WebPartZone's smart tag and select Edit Templates.
9. Drag and drop an instance of the MyCalendar.ascx user control from the Solution Explorer to the default.aspx page immediately below the Daily Links, so it looks like Figure 14.
10. On the Common WebPartZone Tasks smart tag, click End Template Editing.
11. Run the application, and you will see your calendar appear just below the Daily Links. You can click the Personalize This Page link to set properties for this new Web Part.

Investigating New Server Controls

As if all the previous functionality wasn't enough, the current version of ASP.NET Whidbey has added 38 new server controls! Obviously, we can't describe them all here (we haven't even managed to investigate them all), we'll try to point out some of the interesting new controls, focusing on new user interface elements and new data source controls.

It's also interesting to note that in ASP.NET Whidbey, all the server controls are device-aware. Rather than requiring you to create separate applications for rich browsers and for mobile devices, all the controls now can be used for either type of browser. ASP.NET renders the output correctly, depending on the type of device making the request for the page.

The BulletedList control allows you to display a bulleted list in almost any format you wish. (You could do this in ASP.NET 1.x using a Repeater control, but that seemed like a lot of effort.) All you have to do now is to bind this control to a data source (such as the DataSetDataSource), set the BulletStyle property to one of its many options, and it produces output that looks like Figure 15.

Although it was possible in ASP.NET 1.x to download and incorporate a somewhat complex TreeView control, ASP.NET Whidbey includes a full-featured, easy-to-use TreeView control. With little or no code, you can easily bind the TreeView control to a data source, and display hierarchical data. Figure 16 shows a simple menu structure you can generate with just a little XML data and by setting a few properties.

To create your own TreeView control as shown in Figure 16, follow these steps:

1. In the Solution Explorer window, right-click the Data folder, and select Add New Item from the context menu.
2. Select XML File from the list of templates, and name the new file Menus.xml.
3. In the Solution Explorer window, double-click Menus.xml to load it into the code editor, and add the following XML data. Save the file when you're done.

<?xml version="1.0" encoding="utf-8"?>
<Menus>
 <Menu Text="Browsing the Web Offline">
    <SubMenu Text="Making Web Pages Available Offline" />
    <SubMenu Text="Viewing Web Pages without being Connected" />
    </Menu>
    <Menu Text="Printing and Saving Information">
        <SubMenu Text="Printing and Saving Information" />
        <SubMenu Text="Saving a Web Page on Your Computer" />
        <SubMenu Text="Saving Text from a Web page" />
    </Menu>
</Menus>

2. In the Solution Explorer window, right-click on the topmost node (the root folder) and select Add New Item from the context menu. Add a new Web Form, and name the page TreeView.aspx. If necessary, switch to Design view.
3. From the Toolbox window, select the Data tab, and drag an XmlDataSource control onto your page.
4. From the new control's smart tag, select the Configure DataSource link. In the Data File text box on the Configure Data Source dialog box, enter the path to your XML file (Data/Menus.xml) or click the browse button to browse to the location. Click Finish to dismiss the dialog box.
5. In the Toolbox window, select the Core tab, and add a TreeView control to the page.
6. In the TreeView control's smart tag, select the Auto Format link, and select the Windows Help option.
7. In the TreeView control's smart tag, select the Connect to DataSource link, and select the XmlDataSource1 option from the list of available data sources.
8. Select the Edit Bindings option from the smart tag, displaying the TreeView Bindings Editor dialog box.
9. In the Available Bindings list, select the top item, Menus, and then click Add.
10. In the Binding Properties grid to the right, set the Text property to Help Topics.
11. In the Available Bindings list, select the next item, Menu, and then click Add.
12. In the Binding Properties grid to the right, set the TextField property to Text. (This indicates which attribute of the Menu item within the XML you'd like to display for this node in the TreeView control.)
13. In the Available Bindings list, select the next item, SubMenu, and then click Add.
14. In the Binding Properties grid to the right, set the TextField property to Text.
15. Uncheck the Auto-Generate Bindings check box in the lower left of this screen. Your dialog box should look like Figure 17.
16. Click the OK button to save the changes.
17. In the Solution Explorer window, select TreeView.aspx, and press F5 to run your project. Your page appears, showing the TreeView control as in Figure 16. (Note that pressing F5 now runs the selected page?you don't have to set the start page explicitly.)

Data Binding Controls

ASP.NET Whidbey provides several options for binding to data. You've already seen the SiteMapDataSource, XmlDataSource, and DataSetDataSource controls in use, but these are just a few of the different data sources provided by ASP.NET for use in Web pages. You can drag each of the controls discussed in the following paragraphs from the Data tab of the Toolbox window to any page, and you can bind just about any ASP.NET server control to any of these data sources.

The SqlDataSource control allows you to retrieve data from SQL Server, much as the SqlDataAdapter control did for you in earlier versions of ASP.NET. The real difference is that this control encapsulates both the connection and the command information (whereas the older controls required a separate connection control). You'll find that this control makes it easy to create the SELECT command, and you can then automatically generate the INSERT, DELETE, and UPDATE commands. You have the option of inferring parameters, and can specify how and when the parameter values get fulfilled. Finally, you also have the option of retrieving the schema at design time or at runtime. (Note that the SqlDataSource control uses OLE DB by default, just like the similar controls in the previous version of Visual Studio .NET. You can modify this behavior by tweaking the connection string yourself in the page's source.)

The XmlDataSource control allows you to set up a data source that retrieves its data from an XML stream. You can specify an XML file name, and can optionally specify an XSL transform, so that you can transform the data before binding it to a control. For example, you may need to transform the raw XML before binding it to a TreeView control. You can also specify an XPath query, so that you can filter the data that's returned from the data source.

The DataSetDataSource control makes it easy to bind to an existing DataSet. Of course, because the DataSet is serialized as XML, this means you can also use the DataSetDataSource control to bind other controls to XML. Unlike the XmlDataSource control, the DataSetDataSource control does not allow you to perform XSL transforms or XPath queries on the XML data.

The ObjectDataSource control will turn out to be, we're guessing, one of the most exciting new data binding features in this release of .NET. This control will make all the n-tier purists out there happy?finally, you can bind the user interface to middle-tier objects, as opposed to DataSet objects directly. This control allows you to specify the name of a class and the name of a method within that class that returns a DataSet. We intend to spend a lot more time investigating the possibilities of this control, as we work with later versions of the product.

The AccessDataSource allows you to retrieve information from an Access database. (Actually, MDB files are databases provided by the Jet database engine. Microsoft Access has little to do with it besides being the major consumer of databases created using the Jet database engine, but the name continues to stick.) This control allows you to specify the name of the Access file instead of having to use an OLEDB provider. Otherwise, the control works just like the SqlDataSource control.

The SiteMapDataSource control allows you to treat a site map as a data source for other controls (most specifically, the TreeView control, as you've already seen). This control retrieves data from a special XML file named app.sitemap. The XML file has a very specific schema associated with it, so you must be careful to follow the rules. The following code shows an example from the default Intranet Site template: You can see the Home and the Sales nodes in this XML, and those are the nodes that show up in the upper-left corner of the master page in the default Intranet site:

<?xml version="1.0" encoding="utf-8" ?>
<siteMap>
    <siteMapNode title="Home" url="default.aspx">
        <siteMapNode title="Sales" url="Sales.aspx" />
    </siteMapNode>
</siteMap>

Summary

It looks to us like the ASP.NET team at Microsoft has spent a great deal of time looking at the kinds of sites people create. They've done a great job encapsulating much of the common code and functionality into server controls, so developers can spend more of their time on designing great sites and less on rebuilding components other developers also have to build. From the ability to create master pages that define the look of an entire site, to the new security and personalization controls, to the simpler data sources, we're totally impressed with what we've seen in the new version. We can hardly wait to get started building applications using all these new toys. One thing's for sure: sites we build using ASP.NET Whidbey require a lot less code than those we wrote for earlier versions. And that's a good thing.