04 Nisan 2012 Çarşamba 16:00
I'm using VS 2008 running on Windows Server 2008 Standard R2. I created a custom application for ArcGIS/ArcObject extension using C#. However, when I run in Debug Mode (F5), the breakpoints are not being hit; there's no error message either.
I've configured the app to run on x86 platform, .NET Framework 3.5. The application has an Output Type of Class Library, so no executable is created. It creates a tool for ArcGIS ArcToolbox. So when I debug, it usually starts from an external program (ArcCatalog.exe).
Some of my projects of the same type debug without problem. Can't understand why this particular one doesn't hit the breakpoints.
Appreciate any help.
04 Nisan 2012 Çarşamba 17:09Moderatör
You cannot directly debug a class library. In order to get the debugger to work correctly you'll need to configure your class library to start the external program. Then start the debugger via F5. When the external app loads you'll need to do whatever it takes to trigger the loading of your class library. Once the class library is loaded the BP icon that VS shows will change to a red dot (it will be a hollow dot until the library is loaded. If the BP has a warning icon overlay or it is still a hollow dot then the BP won't be hit.
If that doesn't work then the alternative approach is to start the external app normally then use Attach to Process to attach the debugger to the process and then you can set a BP. Note that some apps do odd things with addins so it is possible the external app doesn't actually load the binary that you are attempting to debug. Attaching generally works around this issue but you can use the Modules window to determine if your addin is being loaded from the path you think it is. If not it might be necessary to copy the PDB from the output directory to the directory where your addin is being loaded from.
Michael Taylor - 4/4/2012
04 Nisan 2012 Çarşamba 19:57
I've set the project to start the external program (ArcCatalog.exe) when debugging. It's hitting some of the breakpoints but NOT the breakpoints for the methods (which is what I need to look at to see why it's not doing what it's supposed to be doing.
I also tried the Attach to Process approach but it's still not hitting the breakpoints.
Oh, well. ArcObjects are always a pain to code.
Thanks for the information.
04 Nisan 2012 Çarşamba 20:33Moderatör
If all the code resides in the same assembly, the code compiles sucessfully and you can set a BP in some code and the BP gets hit but not in other areas of the code then those blocks aren't being executed. I would recommend that you use View Call Hierarchy to find all calls to the methods that aren't being hit and set BPs on where they are called to confirm the code paths are executing the way you expect. You can also try calling Debug.WriteLine in the areas where the BPs should be hit and confirm the entries are being written to the Output window. This would confirm the code is running but the BP is still not being hit. Also be sure to verify that the binary you're debugging matches what the program is loading.
The exception to the above applies to code that runs before the debugger gets control (when attaching to a process) such as service init code. Another exception is in code that is dynamically generated including lambda expressions where the code that is written might differ from the code that is run. Normally BPs work with lambdas but I've seen a couple of cases where BPs aren't hit.
Michael Taylor - 4/4/2012
- Yanıt Olarak İşaretleyen Leo Liu - MSFTModerator 12 Nisan 2012 Perşembe 09:04