Creating and Debugging ASP.NET Applications

The process of creating, debugging, and deploying ASP.NET applications is slightly different than the process for building and deploying Windows Forms applications. This section familiarizes you with the tools and techniques involved in building, deploying, and debugging ASP.NET applications.

Building and Deploying ASP.NET Applications

The first step toward creating an ASP.NET application is the creation of a new website from within Visual Studio 2005. When you create a new website, Visual Studio prompts you for the location of the site. You can store the website on the file system, on a remote server via HTTP, or on a remote server via FTP. This is a new feature that previous versions of Visual Studio did not support. Prior to ASP.NET 2.0, you couldn't create web applications without having a copy of IIS on your development server. This new model allows you to create web applications that can be hosted by Visual Studio 2005's own custom local web server without the need for an IIS installation.

Deploying your web applications after they've been created has also become a lot easier in Visual Studio 2005. If you click the Website top-level menu item and then click Copy Web Site, you will see the website copy screen shown in Figure 22.3.

Figure 22.3. Website copy screen.

What you can see from the figure is that you can deploy your website to any location, whether it's accessible via HTTP, FTP, or the file system (so long as you have the appropriate credentials for the destination location). This gives you incredible flexibility in allowing you to deploy your website to development, staging, and production servers all directly from your own workstation within Visual Studio 2005.

ASP.NET applications compile within Visual Studio in the same manner as other applications. The main difference is that the partial class technology creates classes that are combined from the contents of the .aspx files, .ascx files, and so on, and compiles all of those into an assembly used by ASP.NET to service page requests. You will be able to see compile-time errors such as type mismatches, syntax errors, and many more that you would never be able to see in interpreted scripting environments, such as legacy ASP using VBScript or JavaScript.

Debugging ASP.NET Applications

You can debug your ASP.NET applications from within Visual Studio 2005, including the ability to stop on breakpoints, step through individual lines of code, and make use of the Immediate window. The only real concern is that if you are debugging code on a remote server via HTTP, that server needs to be configured to allow remote debugging.

To experiment with debugging an ASP.NET application, start up the application created in Listing 22.1 and insert a few breakpoints wherever you like. Then, run the application in debug mode (F5), and you will see that even though you're working with a web application, the code will still stop on the breakpoints, and you still have access to all of the features of the runtime debugger from within Visual Studio.

Two classes facilitate logging trace and debug messages from within an ASP.NET application. The first is the System.Diagnostics.Debug class, which allows you to write simple information to the debug window. The second, which is specific to ASP.NET, is the System.Web.TraceContext class. This class is provided in the trace property of every page and allows you to output debug information to the ASP.NET trace. Using an ASP.NET configuration file, you can have that trace information automatically displayed at the bottom of a page's rendered output or in the output of a special page called trace.vxd.

The following are a few lines of code that show how to use these two classes from within an ASP.NET page:

Trace.Write("Debug information"); Trace.Write("Diagnostics", "Event X took 10 seconds."); Trace.Warn("Something bad happened."); System.Diagnostics.Debug.WriteLine("Debug information");