Debugging is how you find and fix errors in your programs. In classic Active Server Pages (ASP), developers mainly relied on Response.Write statements to track down issues. The Script Debugger available at that time wasn't nearly as sophisticated as the debugging tools Windows developers had for Visual Basic and C++ applications.
The .NET Framework changed everything. The Common Language Runtime provides integrated debugging for all applications, giving ASP.NET developers the same powerful debugging capabilities that desktop developers enjoy. You can now set breakpoints, inspect variables, step through code, and use all the modern debugging features you'd expect.
The .NET Framework's debugging capabilities address several important requirements:
In-Process and Out-of-Process Debugging: You can debug code running in the same process as your application or in separate processes, giving you flexibility for different scenarios.
Remote Process Debugging: Debug applications running on remote servers, which is essential for troubleshooting production issues or testing in different environments.
Managed and Unmanaged Code: Debug both .NET managed code and native unmanaged code within the same debugging session when working with mixed-mode applications.
Mixed Language Support: Step through code written in different .NET languages (C#, VB.NET, etc.) seamlessly during a single debugging session.
To enable debugging for an ASP.NET page, you need to add a page directive at the top of your file. This directive tells the compiler to include debugging symbols in the compiled output.
<%@ Page Debug="True" Language="C#" AutoEventWireup="true"
CodeBehind="Default.aspx.cs" Inherits="WebApplication1._Default" %>
<!DOCTYPE html>
<html>
<head runat="server">
<title>Debug Example</title>
</head>
<body>
<form id="form1" runat="server">
<div>
<asp:Label ID="lblMessage" runat="server"></asp:Label>
</div>
</form>
</body>
</html>
The Debug="True" attribute is the key. This setting:
Before you start debugging, make sure to view the page in a browser at least once. This ensures the debugging symbols are properly loaded for that specific page.
The .NET SDK includes a debugger that you'll find in the GuiDebug directory. While not as full-featured as the Visual Studio debugger, it provides most of the essential debugging capabilities you'll need.
Available Features:
Limitations:
The SDK debugger doesn't support remote debugging or the Edit and Continue feature. Think of it as a read-only debugger—you can inspect your application's state and step through code, but you can't modify the code inline. When you need to make changes, you'll edit the code externally and restart your debugging session to see the updates.
Just-In-Time (JIT) debugging is a powerful feature that helps you debug programs started outside of Visual Studio. When an unhandled exception or crash occurs in your application, JIT debugging can automatically offer to attach a debugger.
<configuration>
<system.web>
<!-- Enable debugging and JIT debugging -->
<compilation debug="true" targetFramework="4.5" />
<!-- Custom error mode for debugging -->
<customErrors mode="Off" />
</system.web>
<system.diagnostics>
<switches>
<!-- Enable JIT debugging -->
<add name="JitDebug" value="1" />
</switches>
</system.diagnostics>
</configuration>When JIT debugging is enabled and a crash occurs, you'll see a dialog box that allows you to:
This is particularly useful for debugging issues that only appear when running your application normally, outside of a debugging environment.
Use Breakpoints Strategically: Don't just set breakpoints everywhere. Place them at key decision points, before and after critical operations, and where you suspect issues might occur.
Inspect Variables: Use the watch window, locals window, and quick watch to examine variable values. Understanding the state of your data often reveals the source of bugs.
Disable Debugging in Production: Always set debug="false" in your production web.config. Debug mode disables many optimizations and can significantly impact performance.
Use the Call Stack: When an exception occurs, examine the call stack to understand the sequence of method calls that led to the error. This context is invaluable for tracking down root causes.
ASP.NET's integrated debugging support represents a major improvement over classic ASP development. The Common Language Runtime provides sophisticated debugging capabilities that work across all .NET languages and application types.
Whether you're using the full Visual Studio debugger or the SDK debugger, you have access to powerful tools for finding and fixing issues in your code. Features like breakpoints, variable inspection, step-through execution, and Just-In-Time debugging make troubleshooting much more efficient than the Response.Write debugging approach of the past.
Add the page directive <%@Page debug="True" %> at the top of your ASP.NET page. This tells the compiler to include debugging symbols in the compiled page and allows the debugger to attach to the running program.
The SDK debugger (found in the GuiDebug directory) has most features of Visual Studio debugger like breakpoints and variable inspection, but lacks remote debugging and Edit and Continue features. It's essentially a read-only debugger that requires you to edit code externally.
Just-In-Time debugging allows you to debug programs that start outside of Visual Studio. When enabled, you'll see a dialog box when a crash occurs, giving you the option to attach a debugger to investigate the problem.
The integrated debugger provides powerful features like breakpoints, step-through execution, variable inspection, and call stack viewing. Response.Write requires modifying code and can't provide the same level of insight into your application's runtime behavior.
Yes, you should view the web page in the browser first so that the debugging symbols are loaded for that page. This ensures the debugger can properly attach and provide all debugging features.