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

Question

Now and then I run into the following problem:

I start debugging the Add-In and breakpoints are ignored. Almost seems like the communication between the IDE and the component is not working.

My problem is that the last time this had happened I resolved it and now I can't remember what I did to fix it.

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

Partly, the issue I am having is already described here but there is no solution for the actual breakpoint malfunction.

Please note that this normally works.

Deleting the bin and the obj does not seem to work.

This time I just restored my entire project from backup and started over but I would like to know how to fix this should I come across this again.

Answer 1

The only time I have gotten this is when I had another ArcMap instance open and forgot to close it before building/debugging. If you don't close all instances using the assembly then the old one will continue to be used. Or something like that.

Answer 2

Here is an unofficial and still untested solution from ESRI staff. (They did stress that this is not an official solution)

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

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

Answer 3

With Visual Studio, I created a new add-in for Arcmap, and added a button and a toolbar to it. Resulting in a config file looking like this:

<ESRI.Configuration xmlns="http://schemas.esri.com/Desktop/AddIns" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Name>ArcMapAddin4</Name>
  <AddInID>{b6b350bb-084d-42b8-a44a-6dbb6a9f5906}</AddInID>
  <Description>Type in a description for this Add-in.</Description>
  <Version>1.0</Version>
  <Image>Images\ArcMapAddin4.png</Image>
  <Author>Kirk</Author>
  <Company>Microsoft</Company>
  <Date>8/15/2011</Date>
  <Targets>
    <Target name="Desktop" version="10.0" />
  </Targets>
  <AddIn language="CLR" library="ArcMapAddin4.dll" namespace="ArcMapAddin4">
    <ArcMap>
      <Toolbars>
        <Toolbar id="MyToolbar4" caption="MyToolbar4" showInitially="true">
          <Items>
            <Button refID="Microsoft_ArcMapAddin4_Button1"/>
          </Items>
        </Toolbar>
      </Toolbars>
      <Commands>
        <Button id="Microsoft_ArcMapAddin4_Button1" class="Button1" message="Add-in command generated by Visual Studio project wizard." caption="My Button" tip="Add-in command tooltip." category="Add-In Controls" image="Images\Button1.png" />
      </Commands>
    </ArcMap>
  </AddIn>
</ESRI.Configuration>

I created some code in the constructor for the Button and put a break point in it. I started in debug mode and see that the assembly has not yet loaded:

I changed the button to include onDemand=false:

When I started arcmap again, it hit the break point. Note that if the toolbar is off at startup you would need to make it visible to cause the button constructor to be called - so in some ways it is still on demand.

Answer 4

As my project's .NET Framework is 4.0, I changed to supportedRuntime version="v4.0.30319" in ArcMap.exe.config and I noticed that the problem was delayed by this change. I also remembered that ArcMap also loads ArcCatalog so I changed also ArcCatalog.exe.config to supportedRuntime version="v4.0.30319" and YES!!! It's working again. I spent all day trying to fix this and I hope it works for you too.

Answer 5

Aha! Same frustrating situation. Ploughed through the suggestions above for awhile and finally got to a solution. Cutting to the chase, I'll give the solution first, then the explanation:

1. Open Task Manager. End Process for any copy of ArcMap.exe.

2. Open a Windows Explorer. Navigate to C:\Users\\Local Settings\ESRI\Desktop10..

3. If you don't see AssemblyCache, Organize > Folder and search options > View > uncheck "Hide protected operating system files (recommended)"

4. In the directories in AssemblyCache, look for the one containing your .dll.

5. Delete the .dll.

6. Rebuild the project and debug. Once your add in activates you should see the cache contents get refreshed.

7. If desired, re-hide the protected OS files.

The problem for me was that there was an old instance of my DLL in the C:\Users\\Local Settings\ESRI\DesktopX.X\AssemblyCache\ folder, and I also couldn't see \AssemblyCache because I didn't realize it was a hidden OS file. There was also a zombie instance of ArcMap running, and when I tried to delete the DLL initially it was locked. My suspicion is that what caused the problem in the first place is that I didn't quite fully shut down a debugging session of ArcMap before recompiling the code and starting another. The old DLL in the cache couldn't get overwritten because the old ArcMap instance still had it locked, and once it got out of synch with the new code the cached version no longer got updated. (I can see by file dates that the .config, .pdb, and .xml are being updated but not the .dll.)

Answer 6

After I migrated an ESRI ArcGIS 10 project from one machine to the other, I encountered the error that the machine could not load the debug .pdb files for ArcMap.exe. I tried every piece of advice on this post without any luck.

Then I did the following:

I deleted the references for all Esri.* libraries in the each project that contained them, and re-added them to the project on the new machine.

This is what finally worked for me. If anyone stumbles here with this vague issue, and has tried everything else listed on this page, try this - it's quick and easy and pretty harmless. I'm not entirely sure why this had to be done, I'm guessing it has to do with looking up the libraries per machine.

This was for a project that used BaseCommands / Toolbars, and not the new Add-Ins. Using ArcGIS 10.0 and .NET 3.5 with Visual Studio 2010 on Windows 7 Pro.

Answer 7

Two possible causes come to my mind:

1. The addin is not registered properly so the DLL does not get loaded into the ArcMap process being debugged.

2. Your project is targeting .NET 4. Try targeting .NET 3.5 instead.

Answer 8

If you are coding with multiple projects in the same Visual Studio solution, you might encounter situations where Visual Studio (VS) "disables" your breakpoints and you are unable to step through your code. This happened to me recently where I couldn't step into a "dependant" DLL assembly project that was being called from my main project.

VS warnings suggested that my assembly (DLL) was out-of-date and didn't match my code exactly. There are VS options to turn off the requirement that code matches but intuitively this seemed like a bad idea and was backed-up by internet posts. I read many web sites and there are some gnarly suggestions out there.

In the end I did a search for the output DLL from my dependant machine and found several old copies in various locations on my computer (presumably from earlier experiments and project configurations). So I deleted all of them and rebuilt my solution from scratch. This fixed my problem. I guess my current project was inadvertently binding to one of the old copies somehow and not using the latest build that was being placed in my debug folder.

Answer 9

I was dealing with the same problem, with my own add-in in totally other topic, and I inevstigated the followings:

At first, start debug and in the menu choose the following window Debug >> Windows >> Modules, where you can see what modules were loaded at the debug start up. If you can't see there the yourAddIn.dll then at least you know that it was not loaded by the studio. If you see there and you can't put the breakpoint there then the Studio loaded an old one. To check this, change the assembly's name in the project properties, rebuild the solution, start the debug and you will see the old dll loaded there. I don't know from where does the studio load this old dll.

Go to the Solution Explorer and check compare the "yourAddIn.Addin" and "yourAddIn - For Testing.AddIn" files and they may differ. The studio uses only the 2nd file in its Add-In Manager! At first change Also change the tag in it to refer to the correct dll and you may check the tag as well. For me the was set back to 0 in the "yourAddIn - For Testing.AddIn" file, so I changed it back to 1. (If you delete the bin directory of your add-in and starts the studio it will promt you and ask that would you like to remove this add-in from your add-ins list! At this point the Studio sets the LoadBehavior to 0.)

After these two change it started working again!

Answer 10

What worked for me was not deleting the arcmap.config.exe as described in the post by Jakub above, but setting the "supportedRuntime" tag in this file to the correct version of the Framework that you target within Visual Studio, im my case:

<startup>
    <supportedRuntime version="v3.5"/>
</startup> 

Answer 11

Had to change my addin for arcCatalog to match using framework 4 with the new 10.1 version of ArcCatalog.
Just commented out the version="v2.0.50727" and uncommented "v4.0.30319"

In C:\Program Files (x86)\ArcGIS\Desktop10.1\bin the ArcCatlog.exe xml config file

stops on break point now

Seems to be the same issue with arcmap

Answer 12

I had this happen to me once or twice. If I remember correctly, I was able to get the breakpoint working when I made a minor code change, which meant that the application was rebuilt. What happens when you build or rebuild your project?

Answer 13

I can't believe more people are not having this problem. I now run into this almost every time i am improving and debugging my add-ins.

None of the above mentioned solutions work. To fix this I need to delete the entire project and restore it from backup. This leads me to believe that something in the particular project has become corrupt since it usually start happening when ArcMap crashes during debugging.

Answer 14

Over a number of ArcObjects projects I compiled a list of reasons why debugging might not work for add-ins, extensions, and commands (pre-add-in). In no particular order:

1. You are in Visual Studio's Release mode instead of Debug mode
2. Old versions of the tool are still registered with ArcMap / ArcCatalog and these are preventing your debug version from being loaded, or other tools with the same name are registered
3. Project / Solution needs cleaning, and if necessary go into \bin and \obj and delete any lingering files
4. In some cases breakpoints can only be hit after the tool has been activated (on-demand)
5. If no breakpoints are hit it's possible an exception is occurring in the constructor and the tool never runs. Check by showing all CLR exceptions in the debug menu
6. Entries in C:\Users\<name>\Local Settings\ESRI\DesktopX.X\AssemblyCache need deleting

Many steps require ArcMap is restarted. If all else fails a machine restart is an easy fallback but I've only once had this make a difference.