Debugging Microsoft .NET
This session described a full range of techniques for effective debugging under .NET. Most of them were the plain and practical explanations of features that the CLR tools and Visual Studio.NET provide natively.
The key points about .NET debugging are as follows:
-
No more memory leaks, by construction.
-
Ability to make true remote debugging jumps from client to server, and then to another server
-
‘Attach’ and ‘detach’ commands for processes are now available and effective
-
Significant improvements in facilities like breakpoints, tracing and assertions
To enable debugging, the first thing to do is make sure that the proper option is turned on in the environment. For ASP.NET
applications in particular, this means having the attribute debug=true set either at the page level,
or through an application-wide setting within the <system.web> portion of the web.config file.
In ASP.NET the actual process you use to debug is ASPNET_WP.exe.
For Windows Forms applications, enabling the debug means ensuring that the /debug:full option is specified on the command line of the compiler. .NET comes with two key tools for debugging. One is cordbg.exe and the other is dbgclr.exe. The former is a console debugger that works in a command-based manner through the console. Dbgclr.exe, instead, is a version of the same debugger embedded in Visual
Studio.NET.
In VS.NET, you find richly-definable breakpoints. For example, a function breakpoint can stop execution on a given line of a given function – letting you specify certain conditions that have to be met as well. This turns out to be rather useful for Visual Basic and other languages where you can have more instructions on the same line. Breakpoints can be conditional and the condition can be bound to the number of hits the function receives, which really helps if the problem lies in a significantly lengthy loop.
For remote debugging, the only thing that matters is that you belong to the
DebuggerUser group on the remote machine. Notice that being a DebuggerUser member doesn’t require Administrator privileges and being an Administrator doesn’t automatically enable you to perform remote debugging.
Tracing has been improved and standardised and all the classes you need have been gathered in System.Diagnostics. Windows Forms support conditional tracing while in ASP.NET you need extra code to make it conditional. Since tracing can be cumbersome due to excessive verbosity, you can control this through the TraceSwitch class. This means that you use the class for all of your tracing activity, giving it a name upon instantiation. The class can work at various different levels of verbosity and this level can be set and changed without recompiling the application. It is sufficient to write
it in a program.exe.config XML file. Of course, program.exe is a placeholder for the actual name of your executable, but tracing can also have a file or a console output as its target.
In ASP.NET, tracing is enabled at the page level and the Trace object is available globally through the interface of the Page. You set the ASP.NET tracer on and off by using the trace attribute in the @ Page directive. In ASP.NET there's no real native support for assertions, but the presenter showed some code to demonstrate that it could be done.
Overall, a presentation without much code or nitty-gritty details but where several features of Visual Studio played an important role on the stage. All in all, no one fell asleep, so it must have been funny and informative as well.
Dino Esposito
|
|
