In part I we spoke about debugging a web application in Visual Studio 2008 and Visual Web Developer Express edition. Using the debugging tools made available to us. We found that these tools were extremely helpful in isolating and tracking down bugs, if we know how to use the tools correctly.
We found that you can set different break points, view variable values, step in and out of code, change line execution and even change variables and object values within the debugging session. With the debugger you have various windows to help you in your debugging quest. Things like the local variable window and the watch window all aid in finding that elusive bug.
These debugging tools are great when you’re developing an application. But what if you have already deployed an application and you’re finding that some of your users are having problems. As it turns out you can’t re-create those problems on your local machine. I’m sure we’ve all been there. Those pesky users keep complaining about bugs you can never find locally. But they are experiencing them on your deployed copy of the web app, on the internet, intranet or whatever the case might be. But you cannot re-create the bug there either. What you realise is that there might be some slight difference in something that you’re not seeing. How do you find that?
Well fortunately there is a tracing feature that allows you to see how your web app is executing behind the scenes. It allows you to monitor the values of the variables that are used. You can even write statements out to the trace utility for debugging purposes that nobody else will see.
Turning on Trace
Let’s turn that on. Open up your previous application that you created in part one. With your web application open, select the “website” menu then select the “asp.net configuration” on the submenu. Once selected you will notice the Casini web server start up and you will be presented with a user friendly website administration tool in your browser.
You will notice that there are a few different things that you can configure. We are not going to deal with them all in this article because the scope does not allow us to. But just to notice, you can configure the security settings, the application settings and providers.
Click on application configuration or the application tab above. Once you move to the application tab, you will notice all the different things that can be set and configured with this tool.
We can create and manage application settings. These could be strings that would be saved in an XML file to be used later by the application.
You can configure your smtp mail settings, so that your site can successfully send e-mails from your web pages.
You can take the application off line or bring it back online.
Then you can also configure and set debugging and tracing information as well as set default error pages.
Let’s click “configure debugging and tracing”. You will see on the page that appears that debugging has already been set. Here you can turn off debugging if needed. Keep in mind that these setting will be translated to the web.config file, where you can easily change these settings manually.
Click “Capture tracing information”. This will give you access to some more trace settings. What we want to do is select “Display tracing information on individual pages”, and accept all the other default values. Then click the back button on the bottom of the page and then close the browser.
Go back to your application and run it. You will notice that when the application comes up in your browser, that you get a whole bunch of more information that you did have on the page before. This is as a result of us setting the capture tracing information to true.
Here you can see all the trace information that you need. Under the request details you can see things like the session id, the request type, the time, the status code.
Under the “Tracing Information” section, you can see the steps taken in the construction of your web page. Which methods were executed and how long it took. Here you would be able to find out if you have placed some code in the wrong method that is perhaps executing at the wrong time. All from the Preinit to the Render methods.
Under the control tree you can see all the controls that your page contains and the hierarchy of those controls.
You can see application state, session state, what is stored in cookies. What’s in the query string, header information. The object and values in your form.
You can also see server information. Things like the server IP address, the host name, the HTTP_USER_AGENT. In fact anything that will aid you in debugging your application. Anything about the web request, a particular request to a particular web page.
Hiding the trace information from the rest of the world
Now you do not want everybody in the world to see this trace information. How do you then go about enabling this trace information but still keep the rest of the world from seeing it? You do not want your web users to see this information, but you still want to be able to debug a live deployment.
Let’s go back to our configuration tool. Menu – Website->asp.net Configuration->Application Configuration. Select configure debugging and tracing.
One way of making sure that others cannot see your trace information is to make sure that “Display tracing information for individual pages” is selected and that Display Trace output for “Local requests only” is set. What this does is only allow trace information to be displayed when the page is accessed on the same machine that the web page is hosted on.
Another way of viewing this trace information is to deselect the “Display tracing information for individual pages” checkbox. Go ahead and save the new configuration by clicking the back button, and then closing the browser. Now when you run the application you will find your trace information is not displayed in your browser.
So then how do you get a hold of that information? Where is it? Well you will find it through a special page called “trace.axd”. Replace the Default.aspx part of your url in your browser with trace.axd. When you then request this page, you will notice a list of pages that were viewed on you website, whether by you or any other user of your website.
Sidebar Note: If anyone has access to your “trace.axd” file they would be able to view this information as well. Make sure your web server is configured for security correctly.
You can set the number of request that you want to see. Notice that you have only 9 requests remaining. If you have a high traffic website you might want to set that setting a bit higher. I will show you how to do that later.
Writing out trace information
In your trace list, of you click on “view details” of your Default.aspx page. You will see similar trace information as we saw earlier. Using this, will help you to debug your web pages. Let me show you how.
Close your web browser. Then back in your web application.
Not only does that trace information show you the value of your variables, but you can also type in some code to display additional information.
In your “Page Load” event of your web page, type in the following:
Trace.Write(" This is a message to myself to tell me some information about the page load event and how the app is executing ");
Now look at what happened when you run the application again. Go and request the trace.axd page as we did before. Notice now that you have an extra item in the list. The new item is the one that we are interested in. Click on “view details”. You will notice that in the “Trace Information” Section, between the “Begin load” and “End load”, which corresponds to the page load event, there is this little message that you wrote using the Trace object.
So you can write out any values to make sure that it is getting to certain points in your code, with out the fear of having your users seeing that trace information.
Remember I said we can change the number of items we want to appear in our list. Close your browser and go back to your asp.net configuration page, navigate back to configure trace and debugging. Near the bottom of the page you will see a drop down box with a lable, “Number of trace requests to cache”. By selecting the drop down box you can select the number of items you want displayed in your list.
Custom Error Pages
Let’s look at how things can really go wrong and how you can avoid those ugly looking error pages.
If you have opened your previously created application, the one we worked on in part one. You can comment out the code in the button click event and type in the following code.
int userinput;
userinput = int.Parse(TextBox1.Text);
userinput = userinput * 3;
Label1.Text = userinput.ToString();
Now run the application and in the input box enter a number, and click the button. The label then returns an expected value. But if you enter in a character value like “Bob” and click the button, you will get a nasty error message stating that the input string is not in the correct format.
Side bar note: Because you are in debug mode the error message is presented to you in the designer, in a user friendly environment. To find that horrible error page, stop the application and re-run it without debugging by pressing CTRL-F5, and repeat the above experiment. You will then get your horrible error page.
Now we do not want our users to see this unfriendly page. We want a user friendly message to appear that does not frighten our users away. How can we do that?
Once again, close your browser. First we are going to create an error page. To do that, add a new item to your project and select the html page, and name it “ErroPage.html”. When the HTML page appears in the designer, you can then proceed to create and style your own user friendly error page.
In between the body section I typed in my little user friendly message.
Our appologies. Our web server is experiencing a few problems at the moment. Please try again later, or report this to our webmaster.
Now you can style it any way you want. You can make it that your error page has the same look and feel as your web site.
Now go back to your ASP.NET configuration. Select “Application Configuration” But now under the Debugging and tracing section, select "Define Default Error page". By clicking the “Define Default Error Page”, you are given a new page in the configuration whereby you can define the default error page. Select the “Specify a URL to use as the default error page” radio button and then select the custom error page, “ErrorPage.html” that we just created, and click the save button.
Now because you are running the application from the same computer as it is being hosted on, you will still receive the default error page. But trust me on this when I say that other users will see your custom error page, “ErroPage.html” that you created.
Before we finish I just want to take the mystery out of the ASP.NET Configuration tool. Whenever you make a selection and a configuration by using the tool, as I have said before, it translate those settings into XML in you web.config file. So if you open your web.config file, and scroll down a few lines you will notice the sections for trace and custom errors entered into the config file as xml.
Something like:
< customErrors defaultRedirect="~/ErrorPage.htm" />
< trace enabled="true" />
Conclusion
So in conclusion, what we’ve dealt with in part two of this lesson is how to access trace information. How to write and reteive trace information. How to set a custom error page. Finally we found out were all the settings of the asp.net configuration tool is stored. All these things, put to gether with part one of this lesson, will help and aid you in finding and debugging those nasty bugs.