AnsweredAssumed Answered

Problem with Debugging and it appears Registering of custom DLL

Question asked by geonetadmin on May 1, 2014
Latest reply on May 5, 2014 by geonetadmin
Original User: robit2


We have a custom dll that extends ArcObjects for some custom functionality in ArcMap.

We are using .net v4, ArcGIS 10.1, Visual Studio 2010.

I'm having issues hitting the infamous Debuggin "The Breakpoint cannot be currently hit.  No symbols loaded for this document."

It appears for all ESRI files (and third party Ericsson Network Engineer file), that it "Cannot find or open the PDB file." 
That's what shows up under "Symbol Status" in the Modules tab.

I have done a fair amount of online research ... so have tried most or all of the suggested solutions.

I have updated the ArcMap.exe.config as in below :

<?xml version="1.0" encoding="utf-8" ?>
    <!--<supportedRuntime version="v4.0.30319"/>-->
    <!--<supportedRuntime version="v2.0.50727"/>-->
    <supportedRuntime version="v4.0.30319"/>

- I have cleared out the bin and obj folders
- I have cleared out the C:\Users\user\AppData\Local\ESRI\Desktop10.1\AssemblyCache  folder.

The Visual Studio solution Builds fine without errors, the DLL is created, and it "appears" to be successfully Registering, as it does show up in the MxCommands folder using the C:\Program Files (x86)\ArcGIS\Desktop10.1\bin\Categories.exe  utility.

However, when I run ArcMap and go to Customize->Customize Mode ...    then click on the Commands Tab, my new Component Category will not show up ?

Note also ... that my DLL is not showing up in the Modules Tab in Visual Studio.  It builds and Registers ... but it's like it's not 'loading' it or fully "seeing" it ... possibly ?

Any advice/help/ideas ?

Note:  This actually all worked fine a couple weeks ago, with this same dll.  I then tried migrating another different dll over from VS2008/ArcGIS 9.3  over to VS2010/ArcGIS 10.1  environment ..... and that particular solution had this problem ... and then from that point on, even this original 'working' dll had these issues as well.  It seems every project now, on this development machine, has these problems.