|
|
There are not many differences between how you perform the build/debug process in Visual Studio .NET and previous versions of Visual Studio. There are, however, several internal differences that allow debugging across languages now that all the compilers are integrated. It is possible with the new debugger to debug Visual Basic, Visual C++, C#, the Managed Extensions for C++, script, and SQL.
Perhaps the greatest change with the debugging process lies within the IDE itself. As mentioned before, any of the debugging windows in the IDE can now be hidden along the edges of the main window, and a simple hover of the mouse will bring them into view. Also, the four watch windows are now completely independent of one another, and you can finally have up to four different memory view windows, compared to the one you were limited to in the previous version of Visual Studio.
One addition to the debugging process, which Visual C++ developers haven't had but other languages in the Visual Studio family have had for a long time, is an Immediate window. The Immediate window allows you to change variables and execute simple commands during runtime while you are debugging.
Other new features include the following:
Debugging applications written for the .NET Framework or Win32. Because solutions written with the .NET Framework may contain several projects with differing programming languages, Visual Studio has integrated the debugging process to seamlessly transition from the debugging of one language to another without any extra work needed by the user.
Attaching to running applications on either the host or a remote computer. Although the concept of attaching to remote applications isn't new within Visual C++, great work has gone into making this debugging process more robust.
Debugging multiple programs simultaneously by executing them from Visual Studio .NET. This is definitely a welcome addition to Visual Studio. If your solution contains multiple executables, debugging the interprocess communication between them will now be much easier.
Added Visual C++ runtime error checks, to name a few, are notification when assigning a long data type to a shorter one, the use of uninitialized variables, and stack corruption. In addition, you can customize the runtime error checks in a number of ways—one of which is routing the error information to a file or other destination.
Buffer security checks to detect buffer overruns. Rather than trying to figure out why your application has produced a General Protection Fault (GPF), the buffer security check will notify you and gracefully exit.
Setting breakpoints in DLLs that have not yet been loaded. The process of debugging DLLs that your application is dependent on has been made much easier. Simply place a breakpoint within the DLL code without needing to tell Visual Studio about any dependencies.
The Configuration Manager, shown in Figure 1.8, allows you to manage all the configurations of each project currently loaded in Visual Studio .NET. You can determine which configuration to build for each project for each solution configuration. Configurations can be configured to selectively eliminate projects from the build.
As indicated earlier, you can build an entire solution with a single command. You can also selectively build any project within the solution by selecting it in the Solution Explorer and building it directly.
As you can imagine, building a solution with several projects of different types can cause a lot of errors during the build process. Visual Studio .NET includes a nice feature known as the Task List, shown in Figure 1.9, that keeps track of all the errors that need to be resolved. In some languages, such as VB .NET, the Task List keeps an up-to-date list of items that need to be resolved. With Visual C++ .NET, the build process is required to produce the tasks.
|
|
| Top |