8

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:

enter image description here

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#)
  • I had a similar problem with ArcMap 10.3 in combination with Visual Studio 2013. I found all the same posts that you 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. Maybe your ArcCatalog addin uses 4.5 and the ArcMap one 3.5? – Berend Jul 29 '15 at 8:26
  • That's a possibility @Berend. The Target Framework (all configurations) is set to .NET Framework 3.5 Client Profile... should that be 4 or 4 Client Profile? This tool is very old, originally written in VB6, it was converted to .net in ArcGis 9.3 which uses 3.5 so when it was converted to an addin the framework wasn't changed - it compiled and ran OK so I didn't see the need to change it. I really think you're on to something here - something I haven't seen in the other posts. – Michael Stimson Jul 29 '15 at 21:39
  • THAT'S IT @Berend!!! please write that as an answer to collect your bounty. I changed the target framework to .NET Framework 4 Client Profile and the breakpoints became active; I knew there had to be something simple but well hidden that I was overlooking... Thank you so much. Now I can debug this code properly. – Michael Stimson Jul 29 '15 at 21:46
2
+200

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.

  • Thanks Berend. That totally fixed the problem, take the bounty with my compliments. – Michael Stimson Jul 30 '15 at 21:58
1

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:

enter image description here

  • I did the clean, that was one of the first things I did, there are no other projects or 3rd party assemblies (perhaps, this one needs Excel library v12)... do you think the Excel objects are causing this problem? if so, how can I get a pdb file for that - I don't think Microsoft will give me their source code regardless of how old that version is. – Michael Stimson Jul 29 '15 at 2:52
  • Very possible. Simply remove the excel objects, clean and then retry the debug. – Farid Cheraghi Jul 29 '15 at 3:08
  • sharing source code from microsoft is a no. For pdb, google it. – Farid Cheraghi Jul 29 '15 at 3:11
  • 1
    The Excel/ArcObjects is what I need to debug. For some reason it's going through the sheet to about X and stopping. I know that ArcGis v10.x supports Excel spreadsheets however this code, and the associated sheets, originated in ArcGis 9.1 and the sheets are non-compliant (header is on row 3). This post gave instructions on getting the pdb social.msdn.microsoft.com/Forums/office/en-US/… so I'll give it a shot. – Michael Stimson Jul 29 '15 at 3:20
  • 1
    Farid, as it turns out it was a .NET framework version that was causing the problem. This might have something to do with Excel not wanting to play the game with the old version. One of the many Microsoft updates may have messed with the ability to use Excel 12 objects in .net 3.5. – Michael Stimson Jul 29 '15 at 21:50
1

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.

  • I have Visual Studio 2010 Professional, there is a big difference between ArcMap and ArcCatalog as stated in the question... my ArcMap addins debug just fine. When I was writing this as COM (ArcGis 9.3.1) code it worked just fine.... actually, thinking about that, I should make sure that the very old Esri extensions (9.3.1) are gone too. What was it you said in your comment about editing the ArcCatalog.exe.config, can you show me the first half dozen lines please. Try making an ArcCatalog addin that does very little (msgbox should be enough) and see if you can debug it. – Michael Stimson Jul 28 '15 at 21:56
  • @MichaelMiles-Stimson... was that comment meant for this answer? Also, I edited my question to add more information and tested with ArcCatalog. My method works but you can't F5 from within Visual Studio, you need to do a little more work but still achieve the same result without having to deal with config files. – Branco Jul 29 '15 at 13:01
  • Branco, thanks for your thoughtful answer but as it turns out it was a .NET framework version that was causing the problem. – Michael Stimson Jul 29 '15 at 21:48
1

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
  • Thanks for the effort tombumb, all of those were addressed in the linked post.. Berend has the correct answer (this time) as it wasn't one of the usual suspects. – Michael Stimson Jul 30 '15 at 21:59
0

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?

  • I referenced that post in the question. This is not about ArcMap, that works just fine, it is ArcCatalog that's causing the issue. Nice try though. I think I'm going to have to offer a bounty on this one. – Michael Stimson Jul 26 '15 at 21:46
  • Hi @MichaelMiles-Stimson Have you tried editing the ArcCatalog.exe.config ? For the last addin I developed I uncommented this <!--<supportedRuntime version="v4.0.30319"/>--> and instead commented this <supportedRuntime version="v2.0.50727"/> – rowanwins Jul 28 '15 at 5:14
  • I couldn't find <supportedRuntime version="v2.0.50727"/> to comment @rowanwins. Assuming I have a backup and want to delete the line instead what goes in the <startup> enclosure? Is there a reason why this line is commented out? – Michael Stimson Jul 28 '15 at 5:23
  • Perhaps @rowanwins you could put that in as an answer, that would allow for at least a screen shot of what you're trying to express and potentially a few more words and I will investigate it tomorrow... home time! – Michael Stimson Jul 28 '15 at 5:30
0

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.
  • Yes, done that. That was mentioned on one of the stack overflow posts. It has to be something less obvious. – Michael Stimson Jul 29 '15 at 4:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.