Debugging Web Applications

Debugging Web applications is easier in .NET because we are debugging Visual Basic .NET in the code-behind file, but it is still not easy. Debugging a Web application is harder than debugging a Windows application because we have several places to look for bugs. Pesky bugs can hide in the HTML, the code-behind file, some SQL stored procedure, or some script somewhere. Unfortunately, tools for debugging all these things are not as advanced as tools for debugging plain old VB code are.

Fortunately, there are some things you can do that may surprise you. You can set breakpoints in the HTML or ASP supporting a Web page or user control. You can use the same System.Diagnostics tools like Trace , Debug , and Assert that you can use in Windows applications, and you can step into stored procedures right in the Visual Studio .NET IDE, assuming you are using SQL Server. (Read Chapter 12 for more information on debugging stored procedures in VS .NET.) Script and SQL are probably the hardest things to debug because the integrated debugging tools for these two elements are as evolved as the integrated VB code debugger. To further mitigate this problem, try to eliminate or reduce your dependence on everything except code-behind. Of course, you won't be able to completely eliminate your dependence on SQL and script, but if you work from a reliable base of well- tested stored procedures and script, you can still constrain much of your debugging to new Visual Basic .NET code. Gratefully, the integrated debugger works just as well for Visual Basic .NET in Web applications as it does in Windows applications.