The Express Edition of Visual Basic 2010 supports local debugging. This means it supports not only the .NET-related Debug and Trace classes discussed in Chapter 6, but also actual breakpoints and the associated interactive debugging available in all versions of Visual Studio. However, as noted, the full versions of Visual Studio provide enhanced debugging options not available in Visual Basic 2010 Express Edition. Figure 1-9 shows the project debugger startup options from Visual Studio 2010.
The default action shown is actually the only option available to Express users — which is to start the current project. However, Visual Studio 2010 developers have two additional options. The first is to start an external program. In other words, if you are working on a DLL or a user control, then you might want to have that application start, which can then execute your assembly. Doing this is essentially a shortcut, eliminating the need to bind to a running process.
Similarly for Web development, you can reference a specific URL to start that Web application. This is often a mixed blessing, as with ASP.NET 2.0, Visual Studio automatically attempts to start an ASP.NET application based on the page you are currently editing. This is a change from ASP.NET 1.x, which allowed you to define a start page. Because ASP.NET 2.0 does not use project files, the new behavior was introduced. In most cases it works just fine, but if you have a Web application requiring authentication, then in most cases it makes more sense to actually place that URL into the debug settings for your application.
However, developers have three options related to starting the debugger. The first is to apply command-line arguments to the startup of a given application. This, of course, is most useful for console applications, but in some cases developers add command-line parameters to GUI applications. The second option is to select a different directory, a working directory, to be used to run the application. Generally, this isn't necessary; but it's desirable in some cases because of path or permission requirements or having an isolated runtime area.
As noted, Visual Studio 2010 provides support for remote debugging, although such debugging is involved and not configured for simple scenarios. Remote Debugging can be a useful tool when working with an integration test environment where developers are prevented from installing Visual Studio but need to be able to debug issues. However, you shouldn't be limited by just using the debugger for understanding what is occurring in your application at runtime.
Another alternative for determining what is occurring within a remote application is using the Debug and Trace classes. As noted in Chapter 6, the Debug and Trace classes combined with effective error handling, often make it faster and easier to determine remote errors then setting up the remote debugger. However, for those environments where an application runs only on a central server, and for which developers have the necessary permissions to run the debugger but not install a copy of Visual Studio, it is possible to leverage remote debugging.
Finally, as might be expected, users of Visual Studio 2010 who work with multiple languages, and who use tools that are tightly integrated with SQL Server, have additional debuggers. The first of these is support for debugging outside of the CLR — what is known as unmanaged code. As a Visual Basic developer, the only time you should be using unmanaged code is when you are referencing legacy COM components. The developers most likely to use this debugger work in C++.
The next option turns on support for SQL Server debugging, a potentially useful feature. In short, it's possible, although the steps are not trivial, to have the Visual Studio debugging engine step directly into T-SQL stored procedures so that you can see the interim results as they occur within a complex stored procedure.
Was this article helpful?