Debugging Console Applications
Debugging Console Applications Console applications can be debugged in the IDE just as you would debug Windows applications, controls, or Web applications. There are a couple of extra considerations you might want to consider when debugging console applications, and we will cover those briefly in this section. Specifying Command-Line Arguments in the IDEConsole applications are typically run from the Cmd window. While debugging, you might want to start the application from the Visual Studio IDE. If your application needs command-line parameters, as FileSort does, you can indicate those command-line arguments in the Debugging page of the application's Property Pages (see Figure 13.4). To set command-line arguments, select the project name in the Solution Explorer and press Shift+F4. Figure 13.4. Set command-line arguments for a console application in the Start Options section of the Debugging page. Attaching Visual Studio to a Running ApplicationAs an alternative to debugging in the IDE, you might have a tester performing black box testing on your application and the application appears to hang. Instead of shutting down the application and trying to reproduce the problem, you might consider attaching to the already running application. After you have attached to the application, you might more readily be able to figure out what has broken. Starting the Application from the Command PromptTo recreate a hung application scenario, open the InfiniteLoop.sln on this book's Web site. To ensure that the application does not quit before we can attach to it, the Main procedure contains an intentional infinite loop. InfiniteLoop.sln is compiled and then started from the command line. To attach to the running program and begin debugging it, we will need to start Visual Studio .NET, and open the InfiniteLoop.sln. The next section describes the steps for attaching to the running process. Attaching Visual StudioInfiniteLoop.exe is running and appears to be hung. Because we are running outside of the IDE, we need to start an instance of Visual Studio .NET and open the Processes window. From the list of available processes (see Figure 13.5), find the process that you want to attach to, select the process, and click Attach. In the Attach To Process dialog box, check Common Language Runtime process type, uncheck the Native process type, and click OK. Figure 13.5. Attach to a running process to debug a process that is running outside of the IDE. Tip If you want to terminate the running process, you can do so by clicking the Terminate button after you have attached to a process. The Task Manager can be used to achieve this result, too. The Processes dialog box will be updated to show the selected process in the Debugged Processes pane (see Figure 13.6). Click Close. The code view in focus should be the process being debugged (see Figure 13.7). Figure 13.6. The selected process in the Processes pane. Figure 13.7. The InfiniteLoop.exe process stopped at a breakpoint inserted after we attached to it. Tip If you want the process to stop when you stop debugging the attached process, select Terminate This Process from the combo box labeled When Debugging Is Stopped in the Processes dialog box. The execution point is easy to find in our sample application because it was planted. Fortunately, the Visual Studio IDE makes it easy to find the execution point even when it is not contrived. Simply press Ctrl+Break and the IDE will suspend execution and show the current execution point. Having a grasp of where the problem resides, you can add conditional breakpoints to begin figuring out the problem. Debugging on a Remote MachinePerhaps the tester is at a remote site or does not have Visual Studio installed in the testing machine (which is a likely scenario). In this instance you may want to attach to and debug a process running on a remote machine from your development machine. You can select a remote machine name from the combo box labeled Name in the Processes dialog box. Visual Studio defaults to using DCOM to debug applications on remote machines, or you can choose Native-only TCP/IP if you are debugging remotely and cannot use DCOM. Detaching from a Native ProcessIf you attach Visual Studio to a Native process, you will need the dbgproxy.exe service installed and running on your machine before running a Native process, or you will not be able to detach from the process. You can install dbgproxy.exe by entering dbgproxy.exe install at the command prompt. You can start the dbgproxy application from the Services applet or the command line. The commands for starting and stopping the debug proxy application are net start dbgproxy and net stop dbgproxy If you are attaching to CLR applications written in Visual Basic .NET, you do not need to install and run the dbgproxy service. |
 | |
Team-Fly  |
| Top |
