nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Visual Studio fans: someone explain debugging to me

CaleBerkey

All,

I'm a C# developer and know VS well. I developed VBA-backed ArcGIS solutions a number of years ago but am now getting back into GIS dev work. I've stepped through some ESRI examples for creating simple ArcMap Add-Ins and all makes sense, but I'm having problems with my breakpoints and debugging. Before launching into deeper questions, can someone briefly explain what a healthy ArcMap Add-In debug process looks like? As a hint for where I'm going:
1) I'm seeing "The breakpoint will not currently be hit. No symbols have been loaded for this document." problems with the breakpoints.
2) The ArcGIS crash reporter gizmo seems to prevent the debugger from halting the code so I can examine the stack trace. When debugging an ArcMap Add-In and you hit a bug, should Visual Studio then leap into action so I can examine the trace or do I have to examine the dump files?

I'm on VS2010 and ArcGIS 10 on XP.

Thanks tons,

Cale

Encuentra más publicaciones etiquetadas con

Accepted answers

All comments

AlexanderGray

Re-throwing the exception to ArcMap is usually not a good idea unless you know how ArcMap is going to deal with it. If in the middle of an edit operation and you have an onChange listener and you want to abort the edit, in that case throwing an exception will do that. Sinking the exception only is usually not good either. It really depends on the application, the users and the concern for security. Generally giving the user a warning that something went wrong is a good idea. Putting the details in a file or in an application event log is good because you, the developer, can look at it after an error has happened in release code. Some people consider that a security risk because it potentially exposes details of the inner workings (call stack) to the users and will only write to a secure database.

JeffreyHamblin

I usually agree about catch-all exception handlers that eat everything being bad form. However, when any unhandled exception occurs in an Add-In, ArcMap immediately crashes with no information about the error other than the generic ESRI error report dialog.

So, I find it useful during the debugging stages.

Whether the exception should be re-thrown after getting the stack trace depends on whether there is the potential for ArcMap to be left in a corrupt state. But re-throwing removes any chance to save work or continue.

I am actually still waffling on what to do at the release stage. At this time I am still leaning toward eating them, and then displaying a warning depending on the level of the Add-In's potential for corruption.

-Jeff

RichardWatson

IMHO, catching and eating general exceptions is bad form. This issue is discussed extensively on the web and in fact FxCop will raise this as an issue:

http://blogs.msdn.com/b/codeanalysis/archive/2006/06/14/631923.aspx

I might do something like this:

try
{
   // my code
}
catch (Exception e)
{
#if DEBUG
   if (!Debugger.IsAttached)
   {
      Debugger.Launch();
   }
   Debugger.Break();
#else
   // Code to log the problem in production
#endif

   // Rethrow the exception
   throw;
}

JeffreyHamblin

What I do is just wrap everthing in a catch-all exception handler that reports the stack trace. For example, a button Add-In would have:

protected override void OnClick()
{
    try
    {
        // Code, or call to other methods here
        ...
    }
    catch (Exception ex)
    {
        MessageBox.Show(ex.Message + "\n\n" + ex.StackTrace);
    }
}

This also keeps the otherwise unhandled exception from crashing ArcMap.

-Jeff

RichardWatson

Look at the StackTrace on the Exception object.

V_StuartFoote

Cale,

See if these ESRI Symbol Server references are helpful:

[INDENT]For ArcGIS 9.3
[INDENT]http://resources.esri.com/help/9.3/ArcGISDesktop/dotnet/37148c9a-1bd3-4a20-82f1-edc81f9c0347.htm[/INDENT]
For ArcGIS 10
[INDENT]http://help.arcgis.com/en/sdk/10.0/arcobjects_net/conceptualhelp/index.html#//000100000127000000[/INDENT][/INDENT]

Stuart

CaleBerkey

Richard,

Thanks again. I'm able to set breakpoints and can halt the code as expected. When ArcMap crashes I can load the dump file, but when attempting to run it I receive the following message:

"Debugging information for 'ArcMap.exe' cannot be found or does not match. Symbols loaded (source information stripped)."

When I continue debugging, I'm informed of an unhandled exception and have the option of examining what looks like assembler output. I'd like to simply be able to know where my code is crashing and view the stack trace. Any clues?

RichardWatson

I do not use add-ins so I was generically describing the process of debugging DLLs/assembly in ArcMap. If the add-in template automatically sets ArcMap as the startup process then you do not need to do it.

ESRI catches unhandled exceptions, generates a dump file, and (if you let it) reports the crash back to ESRI. If your code is crashing ArcMap then you can repeat the flow while running in the debugger. You could also try attaching the debugger. Finally, you can load generated dump file in Visual Studio in order to view the stack trace.

There may be some way to disable ESRI from catching unhandled exceptions. If that were possible then Visual Studio would launch as the Just In Time debugger.

CaleBerkey

Richard,

Thanks for the reply. It sounds like since you attach the process, you aren't describing add-ins? Is that correct? My impression from what I've looked at so far is that the VS2010 add-in template automatically calls ArcMap.exe as an external process and the debugger is attached that way. Sounds like you're manually attaching to ArcMap?

What about bugs? Using the process you describe does the debugger pick up when bugs occur so you can examine the stack trace?

Thanks,

Cale

RichardWatson

If you want to debug ArcMap then you have 2 choices:
1) Set ArcMap.exe as the startup process for the project that you are building, i.e. your "library", and then hit run/F5.
2) Run ArcMap.exe and then attach Visual Studio as the debugger. I think that it is called something like "Attach to process". Use the Visual Studio instance with the project/library that you want to debug open.

You should build your project/library using the Debug configuration. Make sure that the generated pdb file sits physically next to the dll. When you do that then you should be able to set breakpoints. If that isn't working then you can look at the modules that are loaded (there is a view for that in Visual Studio) and try to figure out where it is getting the DLL.

We do this extensively and it works well.

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.

Enlaces Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.