Unable to debug Esri Addin for ArcCatalog

Question

It was a toss of a coin whether this question is a GIS.SE or StackOverflow question... I'm going with GIS.SE because the problem seems to lie with ArcCatalog.

I have several addins that have been written for ArcCatalog (and also ArcMap); previously I was able to F5 debug the code using breakpoints now all my breakpoints are inactive with the message The breakpoint will not currently be hit. No symbols have been loaded for this document:

I have tried the suggestions from Stack Overflow:

Fixing “The breakpoint will not currently be hit. No symbols have been loaded for this document.”

This Breakpoint Will Not Currently Be Hit, The Source Code is Different from the Original (even after cleaning/rebuilding)

The breakpoint will not currently be hit. No symbols have been loaded for this document

and also

Why can't the breakpoint be "hit" when debugging an ArcGIS 10 Add-In? but this appears to be a different problem.

As this is an Addin (dll) so there is no startup project. I have cleansed all other versions. I made a subtle change to the Esriaddinx file in the message= to confirm the changes were being made - all good, there is no older version.

Whilst cleansing I noticed that addins for ArcCatalog are copied to %USERPROFILE%\Documents\ArcGIS\AddIns\Desktop10.X\{AddInID}\ where ArcMap addins are not.. I have tried copying the pdb file to the addin folder but it seems that the code is no longer being debugged and ArcCatalog has switched/redirected to the copy.

Is there a way to debug with breakpoints addins for ArcCatalog? Note that ArcMap addins and standalone applications debug just fine.

Environment:

• Windows 7 64bit
• ArcGis 10.1
• Visual Studio 2010 Professional (both VB.net and C#)

Answer 1

Upgrading my initial comment to an answer:

I had a similar problem with ArcMap 10.3 in combination with Visual Studio 2013. I found all the same posts that @michael-miles-stimson mentioned, and indeed, at one point I could actually debug and hit a breakpoint. But for some reason that stopped working after a while, and there was no way I could get it to work again.

Finally, I reverted the target framework in my project back from .Net 4.5 to .Net 3.5 and set the supportedRuntime in the .exe.config to v2.0.50727. That solved it for me.

If the ArcCatalog addin uses 4.5 and the ArcMap one 3.5, that would explain the behavior explained in the question.

I don't think it matters if you use the Client or Full version, I always tend to use Full, because at one point, I always seem to be missing a class that's not in the Client version.

Answer 2

Whilst cleansing I noticed that addins for ArcCatalog are copied to %USERPROFILE%\Documents\ArcGIS\AddIns\Desktop10.X{AddInID}\ where ArcMap addins are not

Actually Arcmap Addins are copied to that location after installation too(or a Build in Visual studio).

To solve this problem try these steps:

1. Clean your whole Solution in visual studio by right clicking on the solution and choose Clean Solution

2. if your arccatalog addin project is dependent upon other third party assemblies, then make sure those assemblies have .pdb files (symbol) beside them

3. In visual studio, if you have other projects in your solution that your arccatalog project is dependent on them, then add their project reference instead of their dlls. like this image:

Answer 3

Ok, I just verified I am able to step through code using this process. I am doing this in ArcMap, but I think it should apply to ArcCatalog since the process deals with debugging DLLs and not an ESRI specific item. I confirmed this in both ArcMap 10.2.2 and ArcCatalog 10.2.2. As this is a Windows process dealing with DLLs directly, ESRI software versions shouldn't matter.

I am using Visual Studio to Attach to a Process.

I am able to step through a compiled extension (DLL) using this process when the DLL is invoked in another program.

Here is what I am doing...

In Visual Studio, open up your extension project. I built my extension in VS 2010 C# Express, but I am using VS 2013 Ultimate to do this. I am not sure if Attach to Process is an option in the 2010 Express version. I didn't see it, but it could be hidden somewhere since it was the Express version.

Open up your ESRI product and install the add-in. Now, back in VS, click on Attach to Process and select your ESRI product process. Mine was ArcMap.exe. From here, Visual Studio should attach its debugger to the program and when the DLL is executed that you have open and breakpoints set for, it will stop there. This will act like any other program you're debugging in Visual Studio. It may stretch some debugging into some of the ESRI items although the code is most likely obfuscated so not so useful.

I made sure I installed the add-in from my Release directory for my project. As far as I can tell, ESRI doesn't copy the DLL into one of its folders, but they use their Esri Assembly Registration Utility to register the DLL's location so the system knows where to find it when referenced from an ESRI product.

FYI: I use this process to debug class libraries I write in one project that are being utilized in another. The same theory there should apply ESRI add-ins as they are just class libraries (DLLs) being called into another program. Aside from Visual Studio, I believe any other Windows debugger should be able to attach to the DLL.

PLEASE post comments on this one. I have thought this would work for a while and am very curious to see how others fair with this method.

EDIT I just created a new ArcCatalog add-in, which consists of a simple button. I added a string assignment string stophere = "debugger stopped!"; in the event handler for the button's click event. Through ArcCatalog, it stopped using the Attach to Process method. Visual Studio 2010 info on the process is here.

There are a few things on MSDN about debugging DLLs through various methods in Visual Studio and Windows Debugger. I personally find the Attach to Process better than the starting an external program method and also better than using the remote debugger.

The only downside to this method is that you lose the F5 approach where you debug directly from within Visual Studio. So that means, make changes to your code, install the update, start ArcCatalog, Attach to Process, then hit your break points. However, I find that this method is a pretty good one to know in case you run into problems like you have. This process may be a little longer, but it is a surefire method to get your results.

Answer 4

This is a file I built up over a couple of years wrangling with ArcMap & ArcCatalog extensions & then Add-Ins:

Things that can prevent ArcMap from debugging Add-ins in Visual Studio:

• Release mode rather than Debug mode (if using old non-Add-in approach this can be a problem because most likely the \bin\Debug dll was registered with regasm, not \bin\Release
• Old versions of tools in the UI preventing debug version from being loaded (start ArcMap without Visual Studio, remove all commands & delete all add-ins, close ArcMap)
• Is there a chance the non-Add-in version is being used? If not, dll must be registered
• Never necessary to manually install the add-in for debugging
• Clean solution & project, then manually look through application files and delete all /bin and /obj contents
• Empty out contents of C:\Users\<NAME>\Local Settings\ESRI\Desktop10.0\AssemblyCache
• Ensure any other project \bin locations previously / possibly referenced by ArcMap while debugging don't have previously-built dlls / Add-ins of the same name as the one you're trying to debug (i.e. dot net migration / add-in version clash)
• In some Add-Ins breakpoints will only be viable after the tool's button has been clicked - that's when it is initialised
• If no breakpoints are being hit at all it is possible that an exception is being thrown in the constructor and the tool isn't running. Check this by showing all CLR exceptions through Debug menu -> Exceptions -> check 'Common Language Runtime Exceptions'
• If all else fails, restart

Answer 5

Here is the solution:

Try removing SupportedRuntime from arcmap.exe.config, in the bin directory.

This is the \ArcGIS\Desktop10.0\bin\arcmap.exe.config xml file.

Why can't the breakpoint be "hit" when debugging an ArcGIS 10 Add-In?

Answer 6

Some obvious steps(I suppose you have already tried these..but still).

1. Check if the Mode is still "Debug" instead of release.
2. Delete the "obj" and "bin" folders and rebuild.