|
First, make sure that your projects are set to Debug mode and not Release mode. In Release mode, the debugging information is not generated and breakpoints will not ever break execution of the app. You can try all day to make a break point hit in Release mode and all you are going to do is end up frustrated.
Check your project configurations for each project that is giving you trouble. In Visual Studio .NET 2003, click the "Build->Configuration Manager..." menu item. Once the configuration manager dialog is open, confirm that your projects are set to Debug mode and not to Release mode.
Another common problem for debugging applications is the lack of debugging symbols and debug databases stored in the .pdb files. Make sure that the .pdb files for the assembly you are trying to debug are in your startup path (path where the starting exe is located). If you are trying to debug a MyLibrary.dll that is in the startup path, make sure there is a MyLibrary.pdb file also. If there is not, rebuild the affected project and copy the dll and pdb files to the exe's path. Or try rereferencing the projects to make sure you have the correct linkage. This is a very common problem in that many times a developer will not copy the .pdb files to the output directory alongside the .dll, thinking that the .pdb files are unimportant. They are very important! Make sure they are there in your output directory. Also just make sure that they match build times and so forth to ensure you have the .pdb file that was built when the .dll was built. Everytime you make a change to your source code, make sure you are getting the updated .dll and .pdb files.
Once you have confirmed that you are indeed running the target project in Debug mode and the debug symbols are loaded with the app, run the project again and try your break points. If they are still not working, rebuild all of the affected projects. Many times the source code you are trying to debug with is newer or outdated from the library that you are running in the project output. You might have somehow gotten an older dll linked up that the project is using that simply doesn't contain the same code that you are trying to rebuild. Again, rebuilding your projects and checking your references are your best bets here.
If you are unfamiliar with the keyboard shortcuts used to step around in the source code, open up the Visual Studio .NET options dialog via "Tools->Options..." and choose the "Keyboard" category. You can view the keyboard bindings and shortcut keys used by your current profile by scrolling through the list of commands on the right. Look for the Debug.StepInto and Debug.StepOver commands. These are going to allow you the line by line techniques you so desire. Once you find the command, simply select it to view or change its associated keyboard shortcuts.
Most of the time you are going be using either the older VB6 keyboard layout (F8/Shift+F8), or the newer C#/C++ layout (F10/F11).
I will admit that this can be one of the most frustrating problems to encounter. Do not give up, as one of these is surely your problem and will lead you to a solution. Just take a deep breath and grab a cold Mountain Dew because you might be there a while trying to pin point just exactly what the problem may be.
Cheers and good luck!
Mark
|
