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; } } }

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

JakubSisak

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.

I also posted the a similar question here, but the solution there does not work.

Vind meer berichten getagd met

Accepted answers

Anonymous User

Try removing
<supportedRuntime version="v2.0.50727"/>
from arcmap.exe.config, in the bin directory.

All comments

Anonymous User

Try removing
<supportedRuntime version="v2.0.50727"/>
from arcmap.exe.config, in the bin directory.

JakubSisak

Thanks Sean. That's certainly something I have not yet tried. From which directory should I remove this item. I does not seem to be in the project directory. (This issue is project specific.)

Anonymous User

Its the ArcMap application config file
\ArcGIS\Desktop10.0\bin\arcmap.exe.config

Its an xml file so modify it with notepad. This isn't an official solution by the way....

RAnkeny

I'm recieving the The breakpoint will not currently be hit. The source code is different then the original version message on all breakpoints after following the Migrating ArcGIS 9.3 Desktop and Engine custom components to ArcGIS 10 steps. This occurs on all migrated code as well as a simple 'Hello World' button I created in 10 as a test. Disabling the "Require the source version to exactly match the origional version" option in VS Tools>Options>Debugging fixes this issue, but that doesnt sit right with me.

Is anyone else having this issue with their (NON ADD-IN) projects, and what was done to correct this issue?

StephenKilburn

I encountered the same frustrating problem and eventually found a solution. Cutting to the chase, I'll give the solution first, then the explanation:

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

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

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

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

Delete the .dll.

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

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

JakubSisak

This solution doesn't work.

JakubSisak

Its the ArcMap application config file
\ArcGIS\Desktop10.0\bin\arcmap.exe.config

Its an xml file so modify it with notepad. This isn't an official solution by the way....

This solution doesn't work

RichardWatson

You have to edit the ArcMap.exe.config file if your add-in is using the 4.0 or later framework. Out of the box, this file assumes that you are using the 3.5.1 framework.

If you have done that and your breakpoints are not being honored then attach Visual Studio to ArcMap.exe and look at the modules which are loaded and find your DLL. What you want to do is to find where ArcMap is finding your DLL. If it is not the one that you expect that that is your problem.

pslgisAdmin

I've found that if I have been developing an add in, and I use the add in from a copy of arc map that was not opened by clicking the run button from visual studio, the next time I try to debug or hit a breakpoint, it doesn't work.

I just open arc map, go to add in manager, delete the add in from there. Then the next time I run the project from visual studio, it works.

MarielaDel_Rio

This worked for me, thank you! I uncommented the v4.0 and commented the v2.0

Before:

</startup>

After:

</startup>

MarielaDel_Rio

It worked for me. This was the change, I commented V2 and uncommented V4

</startup>

BerendVeldkamp

I ran into the same problem, and none of the solutions worked for me, at least not on their own. I found one more thing that may have been crucial:

After configuring the project to build on the 3.5 framework, I noticed a build warning in Visual Studios output window: warning : The 'language' attribute in the AddIn element is invalid - The value 'CLR4.5' is invalid according to the project's target framework version - The value should be 'CLR'.

After changing the language attribute in Config.esriaddinx file to CLR, things worked again.

Oh, and one more thing: Initially the breakpoint looks invalid (the breakpoint will not currently be hit). Don't let that fool you, because as soon as the addin is loaded, e.g. by clicking on a button, the breakpoint will be valid.

My other configuration:

Supported runtime: v2.0.50727
Require source files to exactly match the original version: Checked
ArcGIS: 10.3.1
Visual Studio: 2013 Update 4

MarielaDel_Rio

I believe, like you said, the solutions work together. I remember changing the version from V2 to V4 worked, but I also had to ensure the CLR value was the correct one (in my case <AddIn language="CLR4.5" ...) and target CPU x86

CharlesFried

None of these solutions worked for me this time, although at various times in the past one or the other of these techniques did work. There seem to be about a 100 ways that this thing can get off the track and it seems to do that spontaneously, at any time (but especially when there is a deadline looming) and I have wasted literally DAYS messing with these and other solutions trying to fix this. This sucks!

StuartBricker

Berend Veldkamp wrote:
...
Oh, and one more thing: Initially the breakpoint looks invalid (the breakpoint will not currently be hit). Don't let that fool you, because as soon as the addin is loaded, e.g. by clicking on a button, the breakpoint will be valid.
...

This is the clincher for me. I changed the runtime version in arcmap.exe.config as per the "unofficial" solution, and I was still getting the invalid breakpoint message. But just as Berend said, as soon as you start your addin, the breakpoint functions as intended. Thank you for saving me pointless additional troubleshooting!

Doe mee aan het gesprek

Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.

Snelle Links

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