The Basics of an ASP.NET Website

Websites in .NET start with a website project. The website project represents a connection between Visual Studio and the development version of your website (see Chapter 4, "Solutions and Projects," for more information). What is meant by website, however, continues to evolve and expand.

Simple HTML sites with hyperlinks and images are rarely created anymore or even discussed seriously as websites. In fact, .NET has pushed the definition well beyond the original ASP model of HTML and script. Today, a website means web forms, compiled code that links those web forms to a middle tier, master pages, themes, configuration, databases and data binding, DLLs, and so on. Visual Studio 2005 brings these concepts together to define the current view of a .NET website. In the following sections, we will examine the makeup of these sites and how to create and configure them.

Creating a New Web Application Project

A web application project represents a template for a site. This template defines default directories, configuration, pages, and other files and settings. Visual Studio ships with a number of website templates. These templates allow you to define a few different versions of a website. You can also use these templates as a basis to define your own, custom templates (see project templates in Chapter 12, "The .NET Community: Consuming and Creating Shared Code," for more information).

Websites are no longer considered just another Visual Studio project (like Windows forms or a library application). Instead, websites have been elevated and given their own status in Visual Studio. To create one, you choose the New Web Site option from the File menu. This launches the New Web Site dialog box, which is very different from your standard new project dialog box. Figure 13.1 shows an example. We'll look at the many items that make defining a website a unique process.

Figure 13.1. Creating a new website.

Selecting a Visual Studio Website Template

Visual Studio installs five ASP.NET templates by default. You pick a template based on your needs. However, the majority of sites will be built with the standard template, ASP.NET Web Site. The five default ASP.NET templates are as follows:

• ASP.NET Web Site Represents a basic ASP.NET website with an App_Data directory and a Default.aspx web form. This is the template most commonly used to start sites.

• ASP.NET Web Service Represents a site focused on creating a web service (see Chapter 16, "Web Services and Visual Studio," for more details).

• Personal Web Site Starter Kit Generates a site meant for individuals to publish their own personal information such as their resume and links. We provide an overview of this template in the following section.

• Empty Web Site Represents a website project devoid of all folders and files. You use this project container as a starting point. It does not presume folders and files. Instead, you explicitly add these items yourself as required.

• ASP.NET Crystal Reports Web Site Creates a site that leverages Crystal reports for the .NET Framework. Creating this site will not only drop a report in your project and set appropriate references, but will also launch a wizard to walk you through configuring a report.

The Personal Web Site Starter Kit

The most ambitious ASP.NET template is the Personal Web Site Starter Kit. This template generates a full working site that you can customize and use to publish a site about yourself. However, more importantly, this site serves as a nice sample showing how to leverage some of the new features of ASP.NET, such as themes, master pages, and object data binding. Figure 13.2 shows the many files and folders inside this template.

Figure 13.2. The Personal Web Site Starter Kit.

Again, using this sample application can be a good way to explore these concepts further. We will cover most of these concepts throughout the chapter. However, we want to make sure you are aware of this template should you want to walk through a sample in the IDE. Figure 13.3 shows the default version of this site running in a browser.

Figure 13.3. Running the personal website.

Choosing a Website Location

In prior versions of .NET, you were essentially stuck (or boxed in) when creating a location for your development website. You had to be running IIS locally, and you had to store your web application inside the wwwroot folder structure. This severely limited your options.

This model caused a number of problems. The first was that typically your application was spread all over your machine. You would have your solution file and .dll projects inside one directory and your web application buried on your C drive in a special directory.

The second was that this model forced IT managers to allow IIS servers on every developer desktop (or not get work done). This typically broke standard policy. In addition, developers were often running a version of IIS that did not match the version of their servers (Windows Server 2003, for example).

Finally, other developers might have a hosted version of their application or might work off a shared development server. Typically, these developers would have access to the server through FTP or HTTP. However, they had no good way to access these files with these protocols and Visual Studio. Therefore, they were forced to work locally and then worry about deployment onto these servers.

Visual Studio 2005 solves every one of these issues. Your options for connecting to the development version of your application are vastly expanded. You can now work with your application using a local IIS server or not. Instead, you might work with the file system and a runtime development web server. Or you may work on a remote server and connect to it with FTP or HTTP. Let's look at configuring these many location options.

You define the location for your website when creating it or connecting to it. Recall that in Figure 13.1 there was a drop-down list for location. This list contains the values, file system, HTTP, and FTP. Each of these locations requires you to navigate to the appropriate location and provide the appropriate credentials to create your site. Alternatively, you can click the Browse button and navigate to each location individually. Clicking this button launches the Choose Location dialog box. In the following sections, we'll look at the many options of this dialog box.

File System

You can choose any directory on your machine to store the contents of your website. The Choose Location dialog box allows you to navigate the file system and select or create a new folder. Figure 13.4 shows this dialog box for selecting a folder. The Create New Folder button is in the upper-right corner.

Figure 13.4. Selecting a file system location.

If you choose File System for your local website development, then you don't need to have IIS on your machine. Instead, Visual Studio recognizes the content in the directory as a website and runs a local instance of ASP.NET Development Server. This server mimics IIS and can be run and killed on an as-needed basis. You end up with an instance for each website you are currently running, debugging, or even building with Visual Studio.

Each development server instance is listed in your system tray. You can right-click an instance and navigate to it, stop it, or view its details. An example of the development server details window is shown in Figure 13.5.

Figure 13.5. The ASP.NET Development Server details window.

Tip

By default, the development server runs on a random port. However, you can force a specific port for the server. To do so, you select the website and view its properties. Figure 13.6 shows an example. You can set the Use dynamic ports property to False and then force a port number using the Port number property.

Figure 13.6. Forcing a port number for the development server.

Local IIS

Visual Studio still allows you to configure a web application using a local instance of IIS. This capability gives you the benefit of being able to run the server even when you're not developing. It also lets you have more control over the configuration of your site using the IIS administration tool.

Select the Local IIS option to define a website on your local server. Figure 13.7 shows the dialog box with this option selected. There are three buttons in the upper-right corner. In order, these buttons allow you to create a new web application, create a new virtual directory, and delete a selected item. If you choose to create a new virtual directory, you are asked to define a directory name and a folder location where you want to store the site. You are not bound to wwwroot. Instead, you can create your site using any folder. You can also choose to connect to this site via Secure Sockets Layer (SSL). This capability is useful if you need to encrypt sensitive information between the development machine and the server.

Figure 13.7. Creating a website on your local version of IIS.

FTP Site

You can define your website to exist on an FTP server. To do so, you must enter the address of the server and the port and provide appropriate credentials. All FTP rules apply (passwords are not secure). Figure 13.8 shows the FTP website settings. Note that sites created using FTP are run using the local ASP.NET Development Server. FTP is simply used to retrieve and store the files.

Figure 13.8. Defining a website with FTP.

Remote HTTP Site

Finally, you can choose a remote web server to define your website. This is similar to running on IIS locally. However, here you actually can use a shared development server. The development server must have FrontPage Server Extensions applied to allow this type of connectivity. Figure 13.9 shows an example of configuring a site's location to be a remote IIS server.

Figure 13.9. Creating a website on a remote server.

Choosing a Default Programming Language

Visual Studio 2005 allows you to mix the languages you use to develop the items in your site. When you create a web form or a class file, you determine the language in which each individual item is written. However, when you create a new site, you set a default language for the site. This default language is set in the New Web Site dialog box (recall Figure 13.1). Setting this value tells Visual Studio how to generate your template. In addition, it sets the initial value for the setting that controls the default language of new items being added to your site.

Figure 13.10 shows a website with mixed code. There are two web files: one with a code-behind written in VB and one with a C# code-behind. Also, you can mix C# and VB class files. To do this, you have to put the class files into separate directories.

Figure 13.10. A website with mixed VB and C# files.

Understanding the File Makeup of Your Website

A number of files go into the definition of an ASP.NET website. In addition, Visual Studio 2005 adds a number of additional, "special" directories. The following sections provide a reference for the many directories and files that define a .NET website.

Directories

ASP.NET defines a number of folders that it uses to organize and recognize various files that make up your application. These folders have reserved names that mean something special to ASP.NET; therefore, you should use them appropriately. Table 13.1 lists each directory along with a basic explanation of each.

Table 13.1. ASP.NET Directories

Directory	Description
Bin	This folder contains the compiled code (.dll files) that your application references.
App_Code	This folder houses the class files that help to define your application. For example, you could choose to put your business object classes in this directory.
	The code in this directory is compiled together. This includes subdirectories. Therefore, all code in the directory must be of the same language.
App_Data	This directory contains data files used by your applications. This can be an .mdf file (SQL Express) or XML data and so on.
App_GlobalResources	This folder contains the resource files (.resx and .resources) that make up your application.
App_LocalResources	This folder also contains resource files. However, these files are specific to a page or control. They are not global to the application.
App_WebReferences	This folder is used for references to web services. It will contain the web service contract (.wsdl), the schemas (.xsd), the discovery files (disco), and other related files.
App_Browsers	This folder contains browser definition files (.browser). These files are most often used for mobile applications. They define the various capabilities of a given browser.
App_Themes	This folder contains subfolders for each theme in an application. The theme folders contain skins (.skin), styles (.css), and images. See "Creating a Common Look and Feel" later in this chapter.

You can add an ASP.NET directory to your application via the context menu for the site. Figure 13.11 shows this operation and lists many of the ASP.NET-specific content directories.

Figure 13.11. Adding an ASP.NET directory to your website.

Files

Numerous files and file types define a typical ASP.NET website. Of course, there are files that you use often, such as web form, user control, class, and configuration; and then there are those that are rarer, such as skin, resource, and site mapand there are many in between. Table 13.2 lists some of the more common files in an ASP.NET web application.

Table 13.2. ASP.NET Files

File Extension	Description
.aspx	Defines an ASP.NET web form. This is the most common ASP.NET file. See "Creating Web Pages" later in this chapter.
.asmx	Defines an ASP.NET web service. See Chapter 16.
.ascx	Represents an ASP.NET user control.
.asax	Creates a global application class. This class defines application and session-level events.
.cs/.vb	Define a class file. The extension .cs is a C# class file. The .vb extension is a class written in Visual Basic.
.master	Represents a master page. A master page is used to define a common look and feel for an application. See "Master Pages" later in this chapter.
.config	Represents a configuration file for your web application. You use the configuration file to manage settings such as debugging and to store application-specific data (such as an encrypted connection string to a database).
.css	Represents a cascading style sheet. It stores the styles of your application or theme. See "Style Sheets" later in this chapter.
.skin	Represents a skin for one or more controls in your application. A skin is defined for an application theme. See "Themes and Skins" later in this chapter.

You add a new ASP.NET file to your application via the context menu for the site (by right-clicking and selecting Add New Item). Figure 13.12 shows the Add New Item dialog box. The many files that are available to your site are also listed as item templates. Visual Studio will take care to place each file in a special directory if applicable.

Figure 13.12. Adding an ASP.NET file to your website.

Controlling Project Properties and Options

ASP.NET applications have their own set of properties and configuration options. These properties control how an application works, is built, works with the debugger, and so on. You access the properties for your website through the Property Pages dialog box. You can open this dialog box through the context menu for your website. The following sections cover the many options of this dialog box.

References

The references in your application define the code that your application uses by reference. That is, this code is not written as part of this application but exists in another. Figure 13.13 shows the References portion of the Property Pages dialog box.

Figure 13.13. Managing web application references.

Each current reference for the website is listed along with its associated reference type. In the figure, there is a web reference (web service) listed. From this dialog box, you can add a new reference, remove an existing reference, or refresh (update) the reference.

Adding a New Reference

You can add two types of references to your ASP.NET applications: a standard reference or a web reference (we cover web references in Chapter 16). A standard reference can be made to a .dll file that exists as part of another application or project. Establishing this reference will place a copy of the compiled .dll file into your bin directory. The namespaces, classes, and methods will then be available for you to code against.

Figure 13.14 shows the Add Reference dialog box. You can use the tabs across the top of the dialog box to find the specific item you want to reference. If, for example, you are looking to reference a namespace from the .NET Framework, you would select the .NET tab. You can also set references to COM components, browse for .dll files, and view recent references.

Figure 13.14. Adding a new reference to your web application.

Finally, the figure shows project-specific references. These items are projects that exist in the current solution. If you set a project reference, then your references are automatically refreshed when those projects are recompiled.

Build

The Build page of the Property Pages dialog box also allows you to control how your application is built using Visual Studio. Figure 13.15 shows the options that are available.

Figure 13.15. Controlling the build options for your site.

Start Action

The Start Action section of the Build page allows you to define how your application is compiled when you run it from the IDE. There are three options in this drop-down: No Build, Build Page, and Build Web Site (the default). Let's look at each of these options.

The No Build option tells the IDE to just launch the site in a browser without doing any compilation. In this instance, as pages and items are accessed, they are built. Instead of the errors showing in the IDE before you run the application, the errors are displayed in the browser as you find them.

Tip

The No Build capability can be great when you have a large application that contains pages that you are not working on or that have errors (and you intend to avoid). It also speeds the startup time because no pages are precompiled.

The Build Page option tells the IDE to compile only the current startup page or the page you're working on. This capability is very useful if you work on only one page at a time. If the IDE finds errors, they are shown in the IDE before the page launches.

Last, the Build Web Site option, the default setting, tells the IDE to build the entire website and all dependent projects prior to launching into the browser. This capability can be helpful if you are working on a small site by yourself. However, it can also cause longer build times on larger projects.

Build Solution Action

There are two options under Build Solution Action in the Build page. The first, Build Web Site as Part of Solution, indicates whether Visual Studio should include the website as part of the solution's build. The default for this setting is true (or checked). In this case, when you choose Build Solution from the Build menu, the website will also be built. The second option, Enable Code Analysis, indicates whether you want to have the website analyzed by Visual Studio (formerly FxCop) for performance, unused variables, naming standards, and so on. This can be a great tool for ensuring developers are adhering to common .NET coding standards.

Accessibility Validation

The Accessibility Validation options in the Build page allow you to have Visual Studio check your web application for conformance with accessibility standards. These standards ensure your application will work for people with disabilities. The actual standards are covered in the next section. Here, you have two options: enable validation for the entire site or just the current startup page. If these options are enabled, Visual Studio displays accessibility issues in the IDE when you run the application.

Accessibility

The Accessibility page of the Property Pages dialog box allows you to define what checks should be done relative to your site's conformance. Figure 13.16 shows the options for configuring the checks. There are three levels of checks based on two standards: the W3C's Web Content Accessibility Guidelines (WCAG) 1 and 2, and the U.S. government's standards for accessibility (Access board section 508).

Figure 13.16. Managing accessibility options.

Tip

Visual Studio checks only your HTML pages for accessibility standards compliance. It does not check ASP controls because those controls emit their own HTML. Therefore, if you need to check an entire page that combines HTML and ASP, you must copy the HTML from the page and embed it as a separate HTML file in your solution. For more information, see "Walkthrough: Creating an Accessible Web Application" at the MSDN website.

Start Options

The Start Options page in the Property Pages dialog box allows you to define what happens when you start (or run) your application. Figure 13.17 shows the many options available. We'll look at each in the following sections.

Figure 13.17. Configuring the startup options for your application.

Start Action

The Start Action section of the Start Options page is useful for defining what happens when a page is loaded when you start your application through the IDE. The first option, User Current Page, tells the IDE to start the application using the current, active page in the IDE. This capability can be great for developers who work on one standalone page at a time. The next option, Specific Page, allows you to set a startup page. This is akin to right-clicking a page and choosing Set as Start Page. The third option, Start External Program, allows you to specify an .exe file to run (instead of the browser) when you start the application. The Start URL option allows you to send the browser to a different URL when running your application. This capability can be useful when debugging a web service. You might launch a client that uses your web service, for example. Finally, you can use the last option to tell Visual Studio to wait for a request (don't start anything). This, too, can be useful for a web service scenario.

Server

The Server section of the Start Options page allows you to specify a server to be launched for your application. Most applications will leave this set to Use Default Web Server. This represents the file system websites. For scenarios that use IIS or FTP, you will specify a URL to the actual server.

Debuggers

The Debuggers group of options on the Start Options page allows you to set the enabled debuggers used when running your application. By default, only ASP.NET is enabled. You can choose to turn off this setting. You can also add both Native code and SQL Server debuggers to the mix.

MSBuild Options

The final page in the Property Pages dialog box, MsBuild Options, allows you to control precompiling of your application. These options are specific to using the MSBuild compilation tool from the command line. Figure 13.18 shows an example. From here, you can set your precompilation output folder and manage related settings.

Figure 13.18. Managing the options related to MSBuild and ASP.NET.

Note

You can get the same results from the Publish Web Site option in the IDE as you would with the MSBuild command-line application.

Creating Web Pages

ASP.NET web pages (also called web forms) make up the bulk of your web application. You create web pages to define your user interface. Web pages in ASP.NET have both a designer component and an event model. The designer allows you to define the controls and look of a given web page. The event model is used on the server to respond to user interaction (or events). This section looks at the basics of both the web page's designer and its event model.

Adding a Web Page to Your Website

The first step to working with web pages is adding one or more to your website. To do so, you use the Add New Item dialog box and select Web Form from the item templates. Figure 13.19 shows an example of adding a CustomerEdit.aspx page to a website.

Figure 13.19. Adding a new web page to your website.

You have a few options when adding a new web page. First, you can set its name. It is best to use a standard naming scheme and to make sure the name also references the page's primary function. Web page names must be unique in a given directory. The second option is the language on which the form is based. Your website can be made up of C#, VB, and J# web pages. When you define a new page, you can choose its language.

Next, you can indicate whether you want the code for the web page to be in a separate file. ASP.NET 2.0 allows you to create a web form as a single file (code and markup). In fact, you now get IntelliSense in the editor for these types of forms. However, the dominant setting (and default) is code-behind (separate file). Putting code in a new file allows you to manage that code independently of the UI markup. This can be a much cleaner development experience. In addition, ASP.NET 2.0 has a new code-behind model that puts your code into what is called a partial class. This partial class contains only the code that you write. Code that is emitted by the tool or framework is not part of this file. Your code and the tool-emitted code are combined together during compilation. In this way, you are not burdened by code that is really not yours.

The final setting on this form is Select Master Page. This setting tells the IDE that you want your form to use a master page for its default content and layout. We will look at master pages later in this chapter.

Adding Controls to Your Web Page

You add controls to a web page by dragging them from the Toolbox to the form. There are two views of your form: design and source view. The design view allows you to build your form using a visual editor (or designer). This is similar to building a Windows form. You drag items on the page and see how they lay out. The source view allows you to see (and edit) the markup related to the web page. You toggle between these views using the options at the bottom of the form window. Figure 13.20 shows the designer view of a web page. The Toolbox items are on the left of the figure. You can see how to toggle the form's two views at the bottom of the figure.

Figure 13.20. Adding controls to an ASP.NET page.

Tip

You can change how Visual Studio brings up your web forms. You can choose between viewing in source view or design view by default. To do so, choose Options from the Tools menu. You then select the HTML Designer node from the tree. Figure 13.21 shows an example of this window. The Start Pages In group box allows you to modify this setting.

Figure 13.21. Choosing between default source or design view.

Responding to Events

When you write ASP.NET web pages, it is important to understand how the event model works. The event model represents how events are fired on the server when users make requests (or trigger actions). The ASP.NET event model is different from the standard Windows form event model because it combines events that process on a server with the nature of a web application delivered inside a web browser. The basics of the web page event model are as follows:

1. Page InitThis event is called to create the controls used by the web page. It also initializes the properties of these controls. This event is typically created automatically by the IDE.

2. Page LoadThis event is called when the page is loaded and after the controls are initialized. This is a common event for web developers to use. You can use this event to determine whether a user is requesting a page or executing a postback (submitting data). You then call the appropriate code based on this information.

3. Control Specific Event(s)Next, the page framework executes the event or events that are associated with the control the user used to submit the form (if any). For example, if a user clicked a button on your form, the button's click event is called (after page load).

4. Page Pre RenderThis event is called just before the final rendering of the page is sent back to the browser. You can use this event to make changes to the page after all events are called.

5. Page UnloadThis is the last event that is called for the page (after the page is rendered). You use this event to do cleanup. For example, you might close page-level connections or do some form of logging.

These steps represent the basic event model for a page. However, there are additional events for the page. In addition, user controls have their own events that are called during the control-specific event stage. Master pages can also add default processing for all pages. Understanding the events in any given page will always help when you're debugging or trying to achieve a specific result.

Note

For more information on what happens inside the ASP processing framework. see "ASP.NET Application Life Cycle Overview" on the MSDN website. This article provides a detailed view of how ASP works with user requests and renders a page. It also covers application- and session-specific events (inside global.asax).

Adding Page Event Handlers

There are a couple ways to ensure that your event handlers are called by ASP.NET when a page executes. First, you can call them automatically. If you set the AutoEventWireup page-level attribute to true, then ASP.NET will find events that follow the Page_ naming convention and automatically call them at their appropriate time. This approach can be convenient but requires you to recall each event's name so that you can define it appropriately.

You can also explicitly bind page events to methods in your code. In this way, you can use your own event names. You can also let Visual Studio generate the event names (so you don't have to remember them). You do so in the same way you bind events to controls: from the Properties window. However, to access the page's events, you must view the Component Designer for the page. You get there by right-clicking the given page and choosing View Component Designer. Selecting this option opens that page's Properties window including the events. Figure 13.22 shows an example.

Figure 13.22. Adding page events.

The right side of the figure shows the properties for the CustomerEdit.aspx page. Notice that the lightning bolt icon is selected from the Properties toolbar. This shows the events (and not the properties). You can double-click an event in this list to generate a method stub for the given event. You can also choose a method from your code and explicitly bind that to an event.

Adding Control Event Handlers

You add server events to controls in a similar manner. You select the control and view its properties. From the Properties window, you can select the lightning bolt icon to show all the events for the given control. You then double-click an event to add it to your code-behind.