Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

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. enter image description here

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.

share|improve this question
    
Is the "onDemand" xml attribute set to false in your config file? –  Kirk Kuykendall Aug 15 '11 at 19:32
    
I don't have a definitive answer (though it usually means that the debugger can't find the pdb file for the loaded dll), but you can try sifting through these questions on SO to see if they move you in the right direction. –  Michael Todd Aug 15 '11 at 19:33
    
@Kirk, I see no such attribute in the config.esriaddinx file. –  Jakub Aug 15 '11 at 20:00
    
@Michael - thanks. will take a closer look. The problem is that i can be adding functionality to my add-in for months and happily debuggin away and sudenly breakpoints don't work... –  Jakub Aug 15 '11 at 20:01
2  
I've had it happen several times for no apparent reason, too. If I recall, deleting the obj and bin directories resolved it a couple of times, copying the suspect pdb and dll to the bin directory of the current project worked a couple of times, etc. Nothing I can point to that will work every time, though. Good luck. –  Michael Todd Aug 15 '11 at 20:10

16 Answers 16

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.

enter image description here

share|improve this answer
2  
Actually, it is "documented" here resources.arcgis.com/en/help/arcobjects-net/conceptualhelp/… I ran into this problem while coding the ogr-workspace plugin and ended up putting it in the Developer FAQ github.com/RBURHUM/arcgis-ogr –  Ragi Yaser Burhum Oct 26 '12 at 22:09
    
This solved the issue for me as well as another issue I was having of my Debug.WriteLine() messages not being sent to the output window in VS 2010. –  JamesSLC Apr 4 at 1:41

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.

share|improve this answer
    
I tried rebooting the computer opening VS and running the debugger without opening any other instances of ArcMap. It launched ArcMap as per usual bu the "dead breakpoint" problem persisted. –  Jakub Aug 16 '11 at 0:15
    
so i just setup ArcGIS and Visual Studio on another machine (all clean install) and the same thing started happening again. I've tried everybody's suggestion and you seem to be correct. I made sure i kill all open ArcGIS processes and when I do so the breakpoints work. –  Jakub Sep 2 '11 at 0:24

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.

share|improve this answer
1  
I had to delete also bin and obj folders. –  Sabin Kolarov Oct 27 '12 at 6:49

2 years and 2 version later and this is still a problem. Just finished updating/improving all my addins for 10.2 and came across this problem again. Implemented ALL sugestions in this post and nothing worked but I have discovered 1 additional possible problem. Unfortunately, I am not sure if this was the culprit or not because I've also implemented most other possible fixes at the same time.

New find: I realized i've been developing Addins since version 10 on the same machine and after re-installing have not always cleaned up legacy ArcGIS data. I found I had an older version of the culprit addin in a previous version of ArcGIS data in C:\Program Files (x86)\ArcGIS. Since ArcGIS will load the legacy addins there was possibly of some sort of a conflict. I removed all legacy arcgis application data (Desktop10.0, Desktop10.1) leaving only Desktop10.2 and the breakpoint came to life. Again I am not 100% if this is the solution but it may be another item on the list to check for.

I've seen this particular problem being called "the ultimate productivity killer" on another site and I could not agree more.

To sum up here is my current to-do list for the 'dead' breakpoint issue:

  1. Ensure, I am actually running the addin. Having debugger launch the application is not enough - the breakpoint will appear "dead" until I run the addin (button, menu option, etc.)

  2. Delete OBJ and BIN foders from the project directory.

  3. Delete the contents of assebmly chache: C:\Users\User\AppData\Local\ESRI\Desktop10.2\AssemblyCache

  4. Delete all legacy assembly data. (If current version is 10.2 delete Desktop10.0, Desktop10.1 asembly data) There is no proof that this helps or is a part of the problem but there is not reason this data needs to exist so I delete it just in case (C:\Users\User\AppData\Local\ESRI)

  5. As per ESRI's support suggestion; Alter the ArcCatalog and ArcMap config XML (didn't work by itself when I tried but several people have recomended this as a solution, including ESRI support) Locate ArcCatalog.exe.config and ArcMap.exe.config in C:\Program Files (x86)\ArcGIS\Desktop10.2\bin Open each xml in notepad and remove the line <supportedRuntime version="v2.0.50727"/> It’s about the fifth line

  6. Delete all legacy ArcGIS application data from the installation directory. This what worked for me. (probably) Go to: C:\Program Files (x86)\ArcGIS Delete all but current folders for Desktop10.x (i.e. Desktop10.0, Desktop10.1) Only the current Desktop version should remain in this location.

  7. Remove and re-add all project references including non-ESRI references, resave, repeat steps 2 and 3, recompile, run dbugger.

  8. Reboot computer. (This soetimes worked in the past) ALso found this being one of recomended solutions on Stack Overflow.

  9. In Config.esriaddinx - change the button to include onDemand=false: (Kirk's suggestion - see above) This didn't work for me personally.

  10. Rebuild project from scratch. (This worked for me in the past.)

share|improve this answer

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:

enter image description here

I changed the button to include onDemand=false:

enter image description here

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.

share|improve this answer
    
Thanks @Kirk. Since I have restored my project from backup, it seems to work now. I usually debug a procedure that's further down the road; i.e. called from the click even of a button which was the case this time. I am pretty sure the assembly is already loaded at this point. (or should be but it's not for some reason) I will definitely try this solution the next time this happens. –  Jakub Aug 15 '11 at 23:57

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.)

share|improve this answer
    
Yes, this sounds like the correct workaround. –  Jakub Jan 8 '13 at 16:03

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.

share|improve this answer

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.

share|improve this answer
    
Targeting .Net 3.5. I just don't understand why everything would work fine and all of a sudden not. –  Jakub Aug 15 '11 at 20:02

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.

share|improve this answer

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!

share|improve this answer
    
Thank you for sharing your experience and caring to provide us the details. Welcome to our community! –  whuber Jan 24 '12 at 15:25

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> 
share|improve this answer

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

share|improve this answer

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.

share|improve this answer

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?

share|improve this answer
    
I tried rebuilding the project and made several changes but still the breakpoints were "dead"... –  Jakub Aug 15 '11 at 23:59

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.

share|improve this answer
    
Are there lingering ArcMap.exe processes? Sometimes add-ins, extensions, commands etc can hold onto a resource or cause a race condition that prevents ArcMap from exiting completely. –  blah238 Oct 25 '11 at 21:16
    
No ArcMap.exe processes running. I now have a reply from ESRI staff to Try removing <supportedRuntime version="v2.0.50727"/> from arcmap.exe.config, in the bin directory. However, i am not sure where from am I removing this item and I've just restored my project from backup and it is now working. When I know more about this fix i will crash ArcMap during debugging which usually makes this happen and will give it a try. –  Jakub Oct 26 '11 at 13:12

Are you creating your project using Framework 4? I had the same problem, but when I switch to Framework 3.5, it works fine.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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