To create your first Visual Studio application, follow these steps:

Now you have a new plain-vanilla website, and you're ready to begin designing your first web page. But before you go ahead, you might want to know a bit more about how Visual Studio keeps track of your website files using projects (optionally) and solutions. The next two sections have all the details.

Ordinarily, Visual Studio uses project files to store information about the applications you create. Web applications are a little unusual because Visual Studio doesn't necessarily create project files for them. In fact, if you followed the steps in the previous section, you created a new website with no project file.

This system, which is called projectless development, is different from the way Visual Studio works with other types of applications, such as stand-alone components and Windows programs. It's designed to keep your website directory clean and uncluttered and thereby simplify the deployment of your web application. This way, when it's finally time to upload your website to a live web server, you can copy the entire folder without worrying about excluding files that are used only for development purposes. Projectless development is also handy if you're programming with a team of colleagues, because you can each work on separate pages without needing to synchronize project and solution files.

For most web developers, this is all you need to know. However, there's actually another option: project-based development, or web projects. Web projects are the original way of creating ASP.NET web applications, and they're still supported in Visual Studio 2010.

You can create a web project by choosing File

There are a few reasons why you would consider using web projects:

All the examples that are shown in this book use the projectless website model. However, you're free to create web projects if you fit into one of the scenarios just described. You still write the same code to power your web pages. It's really just a matter of taste.

As you've learned, Visual Studio allows you to create ASP.NET applications without project files. However, you might be surprised to learn that Visual Studio still creates one type of resource file, called a solution file. Solutions are a similar concept to projects—the difference is that a single solution can hold one or more projects. Whenever you're working in Visual Studio, you're working with a solution. Often, that solution contains a single projectless website, but in more advanced scenarios it might actually hold additional projects, such as a web application and a component that you're using with your website.

At this point, you're probably wondering where Visual Studio places solution files. It depends, but in a typical projectless web application, Visual Studio quietly tucks the solution files away into the user-specific document directory that's named in this form:

c:Users[UserName]DocumentsVisual Studio 2010Projects[WebsiteFolderName]

This system can get a bit confusing, because the rest of your website files will be placed in a completely different directory.

Each solution has two solution files, with the file extensions .sln and .suo. In the previous section, a new website was created named SampleSite. Behind the scenes, Visual Studio generates the following solution files for SampleSite:

SampleSite.sln
SampleSite.suo

When you open a previously created website, Visual Studio locates the matching solution file automatically and uses the settings in that solution.

The solution files store some Visual Studio–specific details that aren't directly related to ASP.NET, such as debugging and view settings. For example, Visual Studio tracks the files that are currently open so it can reopen them when you resume your website development.

The solution files aren't essential. In fact, if you move your website to another computer (or just place them in another location on your computer), Visual Studio won't be able to locate the original solution files, and you'll lose the information they store. You can also run into trouble if you create two websites with the same name in different locations, in which case the newer solution files may overwrite the older ones. However, because the information in the solution files isn't really all that important, losing it isn't a serious problem. The overall benefits of a projectless system are usually worth the trade-off.

Usually, you can forget about solutions altogether and let Visual Studio manage them seamlessly. But in some cases, you might want to keep a closer eye on your solution files so you can use them later. For example, you might want to use a solution file to open a combination of projects that you're working on at the same time. You'll see this technique in action in Chapter 22, when you develop your own components.

To take a high-level look at your website, you can use the Solution Explorer—the window at the top-right corner of the design environment that lists all the files in your web application directory (see Figure 4-4).

Figure 4.4. The Solution Explorer

Note

Depending on your Visual Studio settings, you may need to click the Solution Explorer tab on the right side of the window to expand it into view. (You can then click the thumbtack icon in the top-right corner of the Solution Explorer to lock it into place so that it's permanently visible.) If you still have trouble finding the Solution Explorer, you can always summon it into view through the Visual Studio menu. Just choose View

The Solution Explorer reflects everything that's in the application directory of a projectless website. No files are hidden. This means if you add a plain HTML file, a graphic, or a subdirectory in Windows Explorer, the next time you fire up Visual Studio you'll see the new contents in the Solution Explorer. If you add these same ingredients while Visual Studio is open, you won't see them right away. Instead, you'll need to refresh the display. To do so, right-click the website folder in the Solution Explorer (which appears just under the Solution item at the top of the tree) and choose Refresh Folder.

Of course, the whole point of the Solution Explorer is to save you from resorting to using Windows Explorer. Instead, it allows you to perform a variety of file management tasks within Visual Studio. You can rename, delete, or copy files by simply right-clicking the item and choosing the appropriate command.

When you create a new website using the ASP.NET Empty Web Site template, the Solution Explorer starts out as a lonely place, with nothing more than a basic configuration file. To start creating your website, you need to add web forms.

As you build your website, you'll need to add new web pages and other items. To add these ingredients, choose Website

You can add various types of files to your web application, including resources you want to use (such as bitmaps), ordinary HTML files, code files with class definitions, style sheets, data files, configuration files, and much more. Visual Studio even provides basic designers that allow you to edit most of these types of files directly in the IDE. However, the most common ingredients that you'll add to any website are web forms—ASP.NET web pages that are fueled with VB code.

To add a web form, choose Web Form in the Add New Item dialog box. You'll see two additional options in the bottom-right corner of the Add New Item dialog box (as shown in Figure 4-5).

Figure 4.5. Adding an ASP.NET web form

The Place Code in a Separate File option allows you to choose the coding model for your web page. If you clear this check box, Visual Studio will create a single-file web page. You must then place all the VB code for the file in the same file that holds the HTML markup. If you select the Place Code in a Separate File option, Visual Studio will create two distinct files for the web page, one with the markup and the other for your VB code. This is the more structured approach that you'll use in this book. The key advantage of splitting the web page into separate files is that it's more manageable when you need to work with complex pages. However, both approaches give you the same performance and functionality.

You'll also see another option named Select Master Page, which allows you to create a page that uses the layout you've standardized in a separate file. For now, disregard this setting. You'll learn how to create master pages in Chapter 12.

Once you've chosen the coding model and typed in a suitable name for your web page, click Add to create it. If you've chosen to use the Place Code in Separate File check box (which is recommended), your project will end up with two files for each web page. One file includes the web page markup (and has the file extension .aspx). The other file stores the source code for the page (and uses the same file name, with the file extension .aspx.vb). To make the relationship clear, the Solution Explorer displays the code file underneath the .aspx file (see Figure 4-6).

Figure 4.6. A code file for a web page

You can also add files that already exist by selecting Website

If you have an existing ASP.NET web application created with an earlier version of Visual Studio, you can migrate it to the ASP.NET world with ease.

If you created a projectless website with an earlier version of Visual Studio, you use the File

Figure 4.7. Opening a projectless website that was created with Visual Studio 2008

If you created a web project with an earlier version of Visual Studio, you need to use the File

Figure 4.8. Importing a web project that was created with an older version of Visual Studio

When you click Finish, Visual Studio performs an in-place conversion, which means it overwrites your web page files with the new versions. Any errors and warnings are added to a conversion log, which you can display when the conversion is complete.

To add an ASP.NET web control, drag the control you want from the Toolbox on the left, and drop it onto your web page. Technically speaking, you can drop your controls onto a design view window or onto a source view window. However, it's usually easiest to position the control in the right place when you use design view. If you drop controls carelessly into the source view, they might not end up in the <form> section, which means they won't work in your page.

The controls in the Toolbox are grouped in numerous categories based on their functions, but you'll find basic ingredients such as buttons, labels, and text boxes on the Standard tab.

Tip

By default, the Toolbox is enabled to automatically hide itself when your mouse moves away from it. This behavior is often exasperating, so you may want to click the thumbtack in the top-right corner of the Toolbox to make it stay in its fully expanded position. And if you inadvertently close the Toolbox, you can show it again by choosing View

In a web form, controls are positioned line by line, like in a word processor document. You can type in ordinary HTML or add ASP.NET controls. To add a control, you need to drag and drop it to an appropriate place. To organize several controls in design view, you'll probably need to add spaces and hard returns (just hit Enter) to position elements the way you want them. Figure 4-9 shows an example with a TextBox, a Label, and a Button.

Figure 4.9. The design view for a page

You'll find that some controls can't be resized. Instead, they grow or shrink to fit the amount of content in them. For example, the size of a Label control depends on how much text you enter in it. On the other hand, you can adjust the size of a Button or a TextBox control by clicking and dragging in the design environment.

As you add web controls to the design surface, Visual Studio automatically adds the corresponding control tags to your .aspx file. To look at the markup it's generated, you can click the Source button to switch to source view (or click the Split button to see both at once). Figure 4-10 shows what you might see in the source view for the page displayed in Figure 4-9.

Figure 4.10. The source view for a page

Using the source view, you can manually add attributes or rearrange controls. In fact, Visual Studio even provides IntelliSense features that automatically complete opening tags and alert you if you use an invalid tag. Whether you use the design or source view is entirely up to you—Visual Studio keeps them both synchronized.

<asp:Button ID="cmd" style="POSITION: absolute; left: 100px; top: 50px;"
 runat="server" Text="Floating Button" ... />

Once you've added a web control to a web page, you'll probably want to tweak it a bit. For example, you might want to change the text in the button, the color of a label, and so on. Although you can make all your changes by editing the source markup by hand, Visual Studio provides an easier option. Just under the Solution Explorer, in the bottom-right corner of the Visual Studio window, you'll see the Properties window, which shows you the properties of the currently selected web control—and lets you tweak them.

To configure a control in design view, you must first select it on the page (either click it once in the design view or click somewhere inside the tag for that control in the source view). You'll know the right control is selected when you see its name appear in the drop-down list at the top of the Properties window. Alternatively, you can select your control by picking its name from the Properties window list.

Once you've selected the control you want, you can modify any of its properties. Good ones to try include Text (the content of the control), ID (the name you use to interact with the control in your code), and ForeColor (the color used for the control's text).

Tip

If the Properties window isn't visible, you can pop it into view by choosing View

Every time you make a selection in the Properties window, Visual Studio adjusts the web page markup accordingly. Visual Studio even provides special "choosers" that allow you to select extended properties. For example, if you select a color property (such as ForeColor or BackColor) in the Properties window, a button with three dots (...) will appear next to the property, as shown in Figure 4-11.

Figure 4.11. The ForeColor property in the Properties window

If you click this button, Visual Studio will show a dialog box where you can pick a custom color (Figure 4-12). Once you make your selection and click OK, Visual Studio will insert the HTML color code into the Properties window and update your web page markup.

Figure 4.12. Choosing a color value

You'll see a similar feature when configuring fonts. First, select the appropriate control on the design surface (or in the list at the top of the Properties window). Next, expand the Font property in the Properties window, and select the Name subproperty. A drop-down arrow will appear next to the property. Click this to choose from a list of all the fonts that are installed on your computer. (Don't go too crazy here. If you choose a font that isn't installed on the computer of the person who is visiting your web page, the browser will revert to a standard font. Chapter 6 has more about font choosing.)

Along with web controls, you can also select ordinary HTML tags in the Properties window. However, there's a lot less you can do with them. Ordinary HTML tags aren't live programming objects, so they don't have nifty features that you can control. And ordinary HTML tags don't offer many options for formatting. If you want to change the appearance of a tag, your best choice is to create a style for your control. If you're a web guru, you can do this by hand. If not, you can use Visual Studio's style building features, which you'll learn about in Chapter 12.

Finally, you can select two objects in the Properties window that need some explanation—<PAGE> and DOCUMENT. <PAGE> includes a number of ASP.NET options that are tied to the page directive—the essential one- or two-line statement that sits at the top of your .aspx files and is described in the next section. The DOCUMENT item is less interesting. It consists of a smaller set of properties, including a subset of the <PAGE> options and a few properties that let you alter the <title> and <body> elements.

If you haven't written HTML pages before, the web page source might look a little intimidating. And if you have written HTML pages before, the web page source might look a little odd. That's because the source for an ASP.NET web form isn't 100 percent HTML. Instead, it's an HTML document with an extra ingredient—ASP.NET web controls.

Every ASP.NET web form includes the standard HTML tags, such as <html>, <head>, and <body>, which delineate the basic sections of your web page. You can insert additional HTML tags, such as paragraphs of text (use the <p> tag), headings (use <h1>, <h2>, <h3>), tables (use <table>), and so on. Along with standard HTML, you can add ASP.NET-only elements to your web pages. For example, <asp:Button> represents a clickable button that triggers a task on the web server. When you add an ASP.NET web control, you create an object that you can interact with in your web page code, which is tremendously useful.

Here's a look at the web page shown in Figure 4-9. The details that are not part of ordinary HTML are highlighted, and the lines are numbered for easy reference:

1  <%@ Page Language="VB" AutoEventWireup="False"
2      CodeFile="Default.aspx.vb" Inherits="_Default" %>

 3  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 4  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

 5  <html xmlns="http://www.w3.org/1999/xhtml">
 6    <head runat="server">
 7      <title>Untitled Page</title>
 8    </head>
 9    <body>
10      <form ID="form1" runat="server">
11        <div>
12          <asp:Label ID="Label1" runat="server"
13           Text="Type something here:" />
14          <br />
15          <asp:TextBox ID="TextBox1" runat="server" />
16          <asp:Button ID="Button1" runat="server" Text="Button" />
17        </div>
18      </form>
19    </body>
20  </html>

Obviously, the ASP.NET-specific details (the highlighted bits) don't mean anything to a web browser because they aren't valid HTML. This isn't a problem, because the web browser never sees these details. Instead, the ASP.NET engine creates an HTML "snapshot" of your page after all your code has finished processing on the server. At this point, details like the <asp:Button> are replaced with HTML tags that have the same appearance. The ASP.NET engine sends this HTML snapshot to the browser.

This summary is just a quick introduction to the ASP.NET web control model. You'll learn much more about web controls and how web forms work behind the scenes in the following two chapters. But before you go any further, it's important to consider a few essential details about ASP.NET web forms. In the following sections, you'll learn about the page directive (lines 1 and 2 in the previous code sample) and the doctype (lines 3 and 4). You'll then take a quick detour to review some of the essential rules of XHTML, the markup language used to create modern web pages.

The Default.aspx page, like all ASP.NET web forms, consists of three sections. The first section is the page directive:

<%@ Page Language="VB" AutoEventWireup="False"
    CodeFile="Default.aspx.vb" Inherits="_Default" %>

The page directive gives ASP.NET basic information about how to compile the page. It indicates the language you're using for your code and the way you connect your event handlers. If you're using the code-behind approach (which is recommended), the page directive also indicates where the code file is located and the name of your custom page class. You won't need to modify the page directive by hand, because Visual Studio maintains it for you.

In an ordinary, non-ASP.NET web page, the doctype occupies the very first line. In an ASP.NET web form, the doctype gets second place and appears just underneath the page directive.

The doctype indicates the type of markup (for example, HTML or XHTML) that you're using to create your web page. Technically, the doctype is optional, but Visual Studio adds it automatically. This is important, because depending on the type of markup you're using, there may be certain tricks that aren't allowed. For example, strict XHTML doesn't let you use HTML formatting features that are considered obsolete and have been replaced by CSS.

The doctype is also important because it influences how a browser interprets your web page. For example, if you don't include a doctype on your web page, Internet Explorer (IE) switches itself into a legacy mode known as quirks mode. While IE is in quirks mode, certain formatting details are processed in inconsistent, nonstandard ways, simply because this is historically the way IE behaved. Later versions of IE don't attempt to change this behavior, even though it's faulty, because some websites may depend on it. However, you can specify a more standardized rendering that more closely matches the behavior of other browsers (like Firefox) by adding a doctype.

There are a small set of allowable doctypes that you can use. By default, newly created web pages in Visual Studio use the following doctype:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

This indicates that the web page uses XHTML 1.0 transitional. The word transitional refers to the fact that this version of XHTML is designed to be a stepping stone between the old-fashioned HTML world and the ultra-strict XHTML world. XHTML transitional enforces all the structural rules of XHTML but allows some HTML formatting features that have been replaced by Cascading Style Sheets (CSS) and are considered obsolete.

If you don't need to use these details, you can step up to XHTML strict using this doctype:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

These are the two most common doctypes in use today.

There are still a few more doctypes that you can use. If you're working with an existing website that's based on the somewhat out-of-date HTML standard, this is the doctype you need:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
 "http://www.w3.org/TR/html4/strict.dtd">

And if you want to use the slightly tweaked XHTML 1.1 standard (rather than XHTML 1.0), you need the following doctype:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
 "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

XHTML 1.1 is mostly identical to XHTML 1.0 but streamlines a few more details and removes a few more legacy details. It doesn't provide a transitional option.

Remember, the ASP.NET server controls will work equally well with any doctype. It's up to you to choose the level of standards compliance and backward compatibility you want in your web pages. If you're still in doubt, it's best to start out with XHTML 1.0 transitional, because it eliminates the quirks in different browser versions without removing all the legacy features. If you're ready to make a clean break with HTML, even if it means a bit more pain, consider switching to XHTML 1.0 strict or XHTML 1.1 (which is always strict) instead.

Part of the goal of ASP.NET is to allow you to build rich web pages without forcing you to slog through the tedious details of XHTML (or HTML). ASP.NET delivers on this promise in many ways—for example, in many situations you can get the result you want using a single slick web control rather than writing a page full of XHTML markup.

However, ASP.NET doesn't isolate you from XHTML altogether. In fact, a typical ASP.NET web page mingles ASP.NET web controls with ordinary XHTML content. When that page is processed by the web server, the ASP.NET web controls are converted to XHTML markup (a process known as rendering) and inserted into the page. The final result is a standard XHTML document that's sent back to the browser.

This design gives you the best of both worlds—you can mix ordinary XHTML markup for the parts of your page that don't change, and you can use handy ASP.NET web controls for the parts that need to be interactive (such as buttons, lists, text boxes, and so on) or the parts that you need to update with new information (for example, a block of dynamic text). This design also suggests that ASP.NET developers should have a solid understanding of XHTML basics before they begin coding web forms. The following sections provide a brief overview that introduces you to the XHTML standard (or refreshes your memory, if you've learned it before). If you already know all you want to know about XHTML, feel free to skip ahead to the "Writing Code" section.

<p>This is a sentence in a paragraph.</p>

<h1>A Heading</h1>
<p>This is a sentence in a paragraph.</p>

<p>This is a <b>sentence</b> in a paragraph.</p>

<p>This is line one.<br />
This is line two.<br />
This is line three.</p>

<img src="happy.gif" alt="Happy Face" />

<p>
Click <a href="http://www.prosetech.com">here</a> to visit my website.
</p>

<html xmlns="http://www.w3.org/1999/xhtml">
  <head runat="server">
    <title>Untitled Page</title>
  </head>
  <body>

  </body>
</html>

<html xmlns="http://www.w3.org/1999/xhtml">
  <head runat="server">
    <title>Untitled Page</title>
  </head>
  <body>
    <form ID="form1" runat="server">
      <div>
      </div>
    </form>
  </body>
</html>

When you switch to code view, you'll see the page class for your web page. For example, if you've created a web page named SimplePage.aspx, you'll see a code-behind class that looks like this:

Partial Class SimplePage
    Inherits System.Web.UI.Page

End Class

You may notice that your code files are surprisingly bare. In particular, they don't have any Imports statements. (As you learned in Chapter 3, Imports statements allow you to access classes in a specific namespace without writing a long, fully qualified name. For example, you can replace the qualified name System.Web.UI.Page with just Page if you import the System.Web.UI namespace.)

As you begin coding with ASP.NET, you'll find that a great many ASP.NET classes are available for you to use, without requiring fully qualified names. That's because many commonly used namespaces are imported. However, they're imported automatically based on the settings in a computer-wide configuration file that you'll learn about in Chapter 5. For the most part, this is a worthwhile convenience. But as you'll see throughout this book, you'll still need to import additional namespaces to get access to more specialized features, such as the classes for reading and writing files and the classes for connecting to SQL Server.

Inside your page class you can place methods, which will respond to control events. For example, you can add a method with code that reacts when the user clicks a button. The following section explains how you can create an event handler.

Most of the code in an ASP.NET web page is placed inside event handlers that react to web control events. Using Visual Studio, you have three easy ways to add an event handler to your code:

Figure 4.13. Creating or attaching an event handler

No matter which approach you use, the event handler looks (and functions) the same.

For example, when you double-click a Button control, Visual Studio creates an event handler like this:

Protected Sub Button1_Click(ByVal sender As Object, ByVal e As EventArgs) _
  Handles Button1.Click
    ' Your code for reacting to the button click goes here.
End Sub

The important part is the Handles clause at the end. This tells ASP.NET to wire up the Click event from the Button1 control to this event handler. (If you want to disconnect your event handler, just remove this part of the code.)

Inside your event handler method, you can interact with any of the control objects on your web page using their IDs. For example, if you've created a TextBox control named TextBox1, you can set the text using the following line of code:

Protected Sub Button1_Click(ByVal sender As Object, ByVal e As EventArgs) _
  Handles Button1.Click
    TextBox1.Text = "Here is some sample text."
End Sub

This is a simple event handler that reacts when Button1 is clicked and updates the text in TextBox1.

You'll learn much more about how the ASP.NET web form model works in the next two chapters. But for the rest of the chapter, it's time to take a small break and consider two of Visual Studio's great coding conveniences: outlining and IntelliSense.

Outlining allows Visual Studio to "collapse" a method, class, structure, namespace, or region to a single line. It allows you to see the code that interests you while hiding unimportant code. To collapse a portion of code, click the minus (-) symbol next to the first line. To expand it, click the box again, which will now have a plus (+) symbol (see Figure 4-14).

Figure 4.14. Collapsing code

You can hide every method at once by right-clicking anywhere in the code window and choosing Outlining

Visual Studio tries hard to make your life easier with a number of automatic time-savers. The most powerful of these is IntelliSense—a group of features that prompt you with valuable code suggestions (and catch mistakes) as you type.

Member List

Visual Studio makes it easy for you to interact with controls and classes. When you type a class or object name, it pops up a list of available properties and methods that match what you've typed so far (see Figure 4-15). It uses a similar trick to provide a list of data types when you define a variable or to provide a list of valid values when you assign a value to an enumeration.

Figure 4.15. IntelliSense at work

Tip

Forgotten the names of the controls in your web page? You can get IntelliSense to help you. Just type the Me keyword followed by a period (which is also known as the dot operator). Visual Studio will pop up a list with all the methods and properties of the current form class, including the control variables.

Visual Studio also provides a list of parameters and their data types when you call a method or invoke a constructor. This information is presented in a tooltip below the code and appears as you type. Because the .NET class library uses method overloading a lot, these methods may have multiple versions. When they do, Visual Studio indicates the number of versions and allows you to see the method definitions for each one by clicking the small up and down arrows in the tooltip. Each time you click the arrow, the tooltip displays a different version of the overloaded method (see Figure 4-16).

Figure 4.16. IntelliSense with overloaded methods

Error Underlining

One of the code editor's most useful features is error underlining. Visual Studio is able to detect a variety of error conditions, such as undefined variables, properties, or methods; invalid data type conversions; and missing code elements. Rather than stopping you to alert you that a problem exists, the Visual Studio editor underlines the offending code. You can hover your mouse over an underlined error to see a brief tooltip description of the problem (see Figure 4-17).

Figure 4.17. Highlighting errors at design time

If you try to run a web page that contains an error, Visual Studio will ask you whether it should continue. At this point, you'll almost always decide to cancel the operation and fix the problems Visual Studio has discovered. (If you choose to continue, you'll actually wind up using the last compiled version of your application, because Visual Studio can't build an application that has errors.)

Whenever you attempt to build an application that has errors, Visual Studio will display the Error List window with a list of all the problems it detected, as shown in Figure 4-18. You can then jump quickly to a problem by double-clicking it in the list.

Figure 4.18. The Error List window

You can also configure the level of error checking Visual Studio performs for markup in your .aspx files. Usually, you'll want to set the level of validation to match the doctype that you're using. Unfortunately, Visual Studio doesn't take this step automatically. Instead, it's up to you to choose the level of validation you want from the drop-down list in the HTML Source Editing toolbar. (If the HTML Source Editing toolbar is not currently displayed, right-click the toolbar strip and choose HTML Source Editing.) The most common validation choices are HTML 4.01, XHTML 1.0 Transitional, and XHTML 1.1. For example, if you choose XHTML 1.0 Transitional or XHTML 1.1, you'll receive a warning in the Error List if your web page includes syntax that's not legal in XHTML, such as incorrect capitalization, an obsolete formatting attribute, or an element that's not properly closed. You'll still be able to run your web page, but you'll know that your page isn't completely consistent with the XHTML standard.

AutoCorrect

Not only does IntelliSense help you code and catch mistakes you make, but it can also suggest corrections with a feature called AutoCorrect.

To see AutoCorrect in action, enter this line of code inside an event handler:

Dim fs As New FileStream("newfile.txt", FileMode.Create)

This line creates an instance of the FileStream class, which resides in the System.IO namespace. However, if you haven't imported the System.IO namespace, you'll run into a compile-time error, and the line will be underlined in blue. Unfortunately, the error simply indicates that no known class named FileStream exists—it doesn't indicate whether the problem is a misspelling or a missing import, and it doesn't tell you which namespace has the class you need. However, AutoCorrect can help.

To see AutoCorrect in action, hover over the error. A red exclamation mark icon will appear that, when clicked, shows a window with the suggested correction (see Figure 4-19).

Figure 4.19. Fixing an error with AutoCorrect

Other problems that AutoCorrect can resolve include automatic data type conversion (if you have Option Strict switched on), misspelled keywords, and missing lines in a block structure.

Visual Studio also provides some cosmetic conveniences. It automatically colors your code, making comments green, keywords blue, and normal code black. The result is much more readable code. You can even configure the colors Visual Studio uses by selecting Tools

In addition, Visual Studio is configured by default to automatically format your code. This means you can type your code lines freely without worrying about tabs and positioning. Visual Studio automatically applies the "correct" indenting. Fortunately, if you have a different preference (for example, you want five spaces instead of four spaces of indenting, or you want to use tabs instead of spaces), you can configure this behavior. Just select Tools

When you run a web application, Visual Studio starts its integrated web server. Behind the scenes, ASP.NET compiles the code for your web application, runs your web page, and then returns the final HTML to the browser. The first time you run a web page, you'll see a new icon appear in the system tray at the bottom-right corner of the taskbar. This icon is Visual Studio's test web server, which runs in the background hosting your website. The test server only runs while Visual Studio is running, and it only accepts requests from your computer (so other users can't connect to it over a network).

When you run a web page, you'll notice that the URL in the browser includes a port number. For example, if you run a web application in a folder named OnlineBank, you might see a URL like http://localhost:4235/OnlineBank/Default.aspx. This URL indicates that the web server is running on your computer (localhost), so its requests aren't being sent over the Internet. It also indicates that all requests are being transmitted to port number 4235. That way, the requests won't conflict with any other applications that might be running on your computer and listening for requests. Every time Visual Studio starts the integrated web server, it randomly chooses an available port.

Visual Studio's built-in web server also allows you to retrieve a listing of all the files in your website. This means if you create a web application named SampleSite, you can request it in the form http://localhost:port/SampleSite (omitting the page name) to see a list of all the files in your web application folder (see Figure 4-21). Then, just click the page you want to test.

Figure 4.21. Choosing from a list of pages

This trick won't work if you have a Default.aspx page. If you do, any requests that don't indicate the page you want are automatically redirected to this page.

Single-step debugging allows you to test your assumptions about how your code works and see what's really happening under the hood of your application. It's incredibly easy to use. Just follow these steps:

You can switch your program into break mode at any point by clicking the Pause button in the toolbar or selecting Debug

When debugging a large website, you might place breakpoints in different places in your code and in multiple web pages. To get an at-a-glance look at all the breakpoints in your web application, choose Debug

Figure 4.24. The Breakpoints window

You can jump to the location in code where a breakpoint is placed by double-clicking it in the list. You can also remove a breakpoint (select it and press Delete) or temporarily disable a breakpoint (by removing the checkmark next to it). This allows you to keep a breakpoint to use in testing later, without leaving it active.

In some cases, you might want to track the status of a variable without switching into break mode repeatedly. In this case, it's more useful to use the Autos, Locals, and Watch windows, which allow you to track variables across an entire application. Table 4-3 describes these windows.

Each row in the Autos, Locals, and Watch windows provides information about the type or class of the variable and its current value. If the variable holds an object instance, you can expand the variable and see its members and properties. For example, in the Locals window you'll see the variable Me (see Figure 4-25), which is a reference to the current object inside of which your code is executing (in this case, the web page). If you click the plus (+) sign next to the word Me, a full list will appear that describes many page properties (and some system values).

Figure 4.25. Viewing the current page object in the Locals window

If you are missing one of the Watch windows, you can show it manually by selecting it from the Debug