Tier Sandboxes

The first question that must be answered to fix a bug is,“Where is it?” Most ASP.NET web applications have three (or more) tiers to them, so finding a bug (particularly a subtle one) in such a large system can at first appear to be a daunting task. The first thing that you can do to get a better handle on the situation is break the system into parts. Because web applications are typically broken into logical tiers already, it only makes sense to use this as the first level of debugging segmentation. For the purposes of this book, we assume a system containing three tiers: a data tier, a business object tier, and a user interface (for example, web page) tier.You can then test each tier and eliminate the ones that are not contributing to the problem. This will leave the tier(s) that you need to concentrate more debugging effort on.

Data Tier

In the context of an ASP.NET web application, the data tier is usually represented by a relational database, but it could also be represented by another data source, such as an Exchange server or Directory Services. Regardless of the data source, to eliminate the data tier from the list of suspects, you must determine three things. The first is whether the data is set up properly in the data source. We can’t tell you how many times we have been frustrated to the point at which we are contemplating tossing the monitor out the window, only to discover that the data was not set up properly or had been changed or removed by one of the other developers on the team. The moral of the story is to establish one or more known test scenarios and verify the data setup for each of the scenarios each time before you run it.

The second thing that you must determine to verify that the data tier is not the source of your problem is to make sure that you can connect to the data source. How you do this is largely determined by the nature of your data source. As an example, if you are connecting to an OLEDB data source, it helps to verify that your connection string is properly formatted and that it contains valid server information and security credentials. A good way to do this is to create what is known as a data link file. To do this, right-click the desktop, select New, and then select Text Document. Rename the new text file that is created to test.udl. During this process, the warning prompt (shown in Figure 3.1) will be displayed.

Click Yes, or just press the Enter key. If you double-click the test.udl file that you just created, the Data Link Properties dialog box is displayed. Select an appropriate data source from the Provider tab, and fill in the connection information on the Connection tab. The Connection tab for a SQL Server connection would look like the one shown in Figure 3.2.

After you finish this, you can test whether a connection to the data source can be achieved by clicking the Test Connection button. A failure at this level indicates that you are unable to even talk to your data source, let alone exchange information with it.

If a connection to the data source can be successfully achieved, then you can run some tests on your data conversations to make sure that they are working properly. As an example, you could execute a SQL Server 2000 stored procedure directly in Query Analyzer with hard-coded parameters to determine whether the results returned are what you expected. Be sure not to test your data conversations through any data component layers such as ADO, ADO.NET, or custom data extraction components because this adds an additional level of ambiguity to your test. Right now, you just want to determine whether the data tier is doing its job. After you have checked the data tier, the business object tier is next.

Business Object Tier

The business object tier is the glue that holds the entire web application together. Because of this, you must determine not only whether there are bugs internal to the tier, but also whether there are bugs in the communication layers between it and the other tiers in the web application. Luckily, making this multifaceted determination is relatively straightforward.

The most common object used as a communication layer between the business object tier and the data tier is ADO. Microsoft’s new .NET architecture comes with a new version of this popular library, ADO.NET. We’ll go into more detail about ADO.NET in later chapters in the book, and we’ll focus on debugging issues with it in Chapter 16,“Debugging ADO.NET.” For now, you can use a simple test to see whether ADO.NET is capable of connecting to your data source properly, as shown in Listings 3.1 and 3.2.

Listing 3.1. A Simple Test to See Whether ADO.NET Connects to the Data Source Properly (C#)

<%@ Page Language="C#" ClientTarget="DownLevel" %> 
<%@ Import Namespace="System.Data" %> 
<%@ Import Namespace="System.Data.OleDb" %> 

<% 
string conString = "Provider=SQLOLEDB.1;" + 
     "Persist Security Info=True;" + 
     "User ID=sa;" + 
     "Password=;" + 
     "Initial Catalog=pubs;" + 
     "Data Source=localhost"; 

OleDbConnection cn = new OleDbConnection(conString); 
cn.Open(); 

if(cn.State==ConnectionState.Open) 
{
     Response.Write("Success!"); 
} 

cn.Close(); 
%> 

Listing 3.2. A Simple Test to See Whether ADO.NET Connects to the Data Source Properly (Visual Basic .NET)

<%@ Page Language="VB" ClientTarget="DownLevel" %> 
<%@ Import Namespace="System.Data" %> 
<%@ Import Namespace="System.Data.OleDb" %> 

<% 
Dim conString As String = "Provider=SQLOLEDB.1;" & _ 
     "Persist Security Info=True;" & _ 
     "User ID=sa;" & _ 
     "Password=;" & _ 
     "Initial Catalog=pubs;" & _ 
     "Data Source=localhost" 

Dim cn As OleDbConnection = New OleDbConnection(conString) 
cn.Open() 

If cn.State = ConnectionState.Open Then 
     Response.Write("Success!") 
End If 

cn.Close() 
%> 

If “Success!” gets rendered to the browser, then you know that ADO.NET (your communication layer between the business object tier and the data tier) is working properly. We’ll go into reasons why it might not be working properly when we discuss ADO .NET debugging more thoroughly in Chapter 16.

The meat of the business object tier is comprised of two major parts. First, there is the intrinsic ASP.NET functionality, such as server controls, user controls, and data binding. Second, there are custom components. The bulk of the rest of this book (Parts III,“Debugging the New ASP.NET Features,” and IV ,“Debugging Related Technologies,” in particular) is dedicated to dissecting each of these topics one at a time, covering how to find bugs in each and how to solve them. For now, suffice it to say that if you have established that your data tier and communication layers are working properly and you are still seeing peculiar or incorrect behavior in your web application, then the business object tier is most likely the source.

Communication with the user interface tier is usually handled through the intrinsic ASP .NET Response object, so this layer is usually working just fine. A simple call to Response .Write() can confirm this. Most of the problems with communicating with the bottom tier of your web application occur for one of two reasons. First, you might not be conveying the proper information. As an example, one gotcha that will plague you in your development efforts (although it is easy to solve) occurs when you forget to add the runat=server attribute to your ASP.NET server controls. This causes server event handlers to fail, and the page cannot maintain state.

The second reason why you might have trouble communicating with the bottom tier of your web application arises in the case of nonuser interface communication such as web services. We will discuss the nuances of debugging web services in Chapter 13, “Debugging Web Services.”

User Interface Tier

Although this book focuses on server-side ASP.NET debugging, it is helpful to know when you are dealing with a bug on the client side (user interface tier). As a general rule, if you are prompted with an error dialog box similar to the one shown in Figure 3.3, then you have a problem with your client-side script.

Unfortunately, not all client-side bugs will generate error dialog boxes. The user interface tier is subject to many of the same subtle logic and functionality bugs that can occur on the data tier and the business object tier. The concepts introduced in this chapter are generic enough to be applied to all tiers in a web application, although a good book on VBScript or JavaScript will provide a better reference on the nuances of client-side programming and its object model.