Pourquoi le point d'arrêt ne peut-il pas être «atteint» lors du débogage d'un complément ArcGIS 10?


24

De temps en temps, je rencontre le problème suivant:

Je commence à déboguer le complément et les points d'arrêt sont ignorés. Il semble presque que la communication entre l'IDE et le composant ne fonctionne pas.

Mon problème est que la dernière fois que cela s'est produit, je l'ai résolu et maintenant je ne me souviens plus de ce que j'ai fait pour le réparer.

Le point d'arrêt ne sera pas atteint actuellement. Aucun symbole n'a été chargé pour le document. entrez la description de l'image ici

En partie, le problème que je rencontre est déjà décrit ici, mais il n'y a pas de solution au dysfonctionnement réel du point d'arrêt.

Veuillez noter que cela fonctionne normalement.

La suppression du bac et de l'obj ne semble pas fonctionner.

Cette fois, je viens de restaurer tout mon projet à partir de la sauvegarde et j'ai recommencé, mais j'aimerais savoir comment résoudre ce problème si je le retrouve.


1
L'attribut xml "onDemand" est-il défini sur false dans votre fichier de configuration?
Kirk Kuykendall

Je n'ai pas de réponse définitive (bien que cela signifie généralement que le débogueur ne peut pas trouver le fichier pdb pour la DLL chargée), mais vous pouvez essayer de passer au crible ces questions sur SO pour voir si elles vous déplacent dans la bonne direction.
Michael Todd

@Kirk, je ne vois pas un tel attribut dans le fichier config.esriaddinx.
Jakub Sisak GeoGraphics

@Michael - merci. va regarder de plus près. Le problème est que je peux ajouter des fonctionnalités à mon complément pendant des mois et que le débogage avec bonheur et les points d'arrêt soudain ne fonctionnent pas ...
Jakub Sisak GeoGraphics

2
Je l'ai eu plusieurs fois sans raison apparente aussi. Si je me souviens bien, la suppression des répertoires obj et bin l'a résolu plusieurs fois, la copie des pdb et dll suspects dans le répertoire bin du projet en cours a fonctionné plusieurs fois, etc. Rien que je puisse signaler qui fonctionnera à chaque fois , bien que. Bonne chance.
Michael Todd

Réponses:


16

Voici une solution non officielle et non encore testée par le personnel d'ESRI. (Ils ont souligné que ce n'est pas une solution officielle)

Essayez de supprimer de arcmap.exe.config, dans le répertoire bin.

Il s'agit du fichier xml \ ArcGIS \ Desktop10.0 \ bin \ arcmap.exe.config.

entrez la description de l'image ici


3
En fait, il est "documenté" ici resources.arcgis.com/en/help/arcobjects-net/conceptualhelp/… J'ai rencontré ce problème lors du codage du plugin ogr-workspace et j'ai fini par le mettre dans la FAQ du développeur github.com/ RBURHUM / arcgis-ogr
Ragi Yaser Burhum

Cela a résolu le problème pour moi ainsi qu'un autre problème que je rencontrais concernant le fait que mes Debug.WriteLine()messages n'étaient pas envoyés à la fenêtre de sortie dans VS 2010.
GeoSharp

J'ai rencontré ce problème ENCORE et c'est ce qui a fonctionné cette fois. J'utilise VS 2010 Express (C #) et je cible .NET 4.0. J'ai dû décommenter la version d'exécution prise en charge par v4.0 et supprimer la référence v2.0.
Radar

8

2 ans et 2 versions plus tard et c'est toujours un problème. Je viens de terminer la mise à jour / l'amélioration de tous mes compléments pour 10.2 et j'ai rencontré à nouveau ce problème. Implémenté TOUTES les suggestions dans ce post et rien n'a fonctionné mais j'ai découvert 1 problème possible supplémentaire . Malheureusement, je ne sais pas si c'était le coupable ou non, car j'ai également implémenté la plupart des autres correctifs possibles en même temps.

Nouvelle découverte: j'ai réalisé que je développais des compléments depuis la version 10 sur la même machine et après la réinstallation, je n'ai pas toujours nettoyé les données ArcGIS héritées. J'ai découvert que j'avais une ancienne version du complément coupable dans une version précédente des données ArcGIS dans C: \ Program Files (x86) \ ArcGIS. Étant donné qu'ArcGIS chargera les anciens compléments, il pourrait y avoir une sorte de conflit. J'ai supprimé toutes les données d'application arcgis héritées (Desktop10.0, Desktop10.1), ne laissant que Desktop10.2 et le point d'arrêt a pris vie. Encore une fois, je ne suis pas à 100% si c'est la solution, mais cela peut être un autre élément de la liste à vérifier.

J'ai vu ce problème particulier être appelé "le tueur de productivité ultime" sur un autre site et je ne pourrais pas être plus d'accord.

Pour résumer, voici ma liste de tâches actuelle pour le problème de point d'arrêt «mort»:

  1. Assurez-vous que j'exécute l'addin. Il ne suffit pas d'avoir le débogueur pour lancer l'application - le point d'arrêt apparaîtra "mort" jusqu'à ce que j'exécute le complément (bouton, option de menu, etc.)

  2. Supprimez les fichiers OBJ et BIN du répertoire du projet.

  3. Supprimez le contenu de chase assebmly: C: \ Users \ User \ AppData \ Local \ ESRI \ Desktop10.2 \ AssemblyCache

  4. Supprimez toutes les données d'assemblage héritées. (Si la version actuelle est 10.2, supprimez Desktop10.0, Desktop10.1 asembly data) Il n'y a aucune preuve que cela aide ou fait partie du problème, mais il n'y a pas de raison que ces données doivent exister, donc je les supprime juste au cas où (C : \ Users \ User \ AppData \ Local \ ESRI)

  5. Selon la suggestion de soutien d'ESRI; Modifiez le XML de configuration ArcCatalog et ArcMap (n'a pas fonctionné par lui-même lorsque j'ai essayé, mais plusieurs personnes ont recommandé cela comme solution, y compris le support ESRI). Localisez ArcCatalog.exe.config et ArcMap.exe.config dans C: \ Program Files ( x86) \ ArcGIS \ Desktop10.2 \ bin Ouvrez chaque xml dans le bloc-notes et supprimez la ligne <supportedRuntime version="v2.0.50727"/> Il s'agit de la cinquième ligne

  6. Supprimez toutes les données d'application ArcGIS héritées du répertoire d'installation. C'est ce qui a fonctionné pour moi. (probablement) Allez dans: C: \ Program Files (x86) \ ArcGIS Supprimez tous les dossiers sauf Desktop10.x (c'est-à-dire Desktop10.0, Desktop10.1). Seule la version actuelle de Desktop doit rester à cet emplacement.

  7. Supprimez et rajoutez toutes les références de projet, y compris les références non-ESRI, réenregistrez, répétez les étapes 2 et 3, recompilez, exécutez dbugger.

  8. Redémarrer l'ordinateur. (Cela a fonctionné dans le passé) A également trouvé que c'était l'une des solutions recommandées sur Stack Overflow.

  9. Dans Config.esriaddinx - changez le bouton pour inclure onDemand = false: (suggestion de Kirk - voir ci-dessus) Cela n'a pas fonctionné pour moi personnellement.

  10. Reconstruisez le projet à partir de zéro. (Cela a fonctionné pour moi dans le passé.)


Jakub, j'ai eu un problème similaire mais non lié gis.stackexchange.com/questions/155016/… - il s'avère que l'héritage était également un problème. La version du framework .net n'était pas à jour, donc si vous avez essayé toutes celles-ci et qu'elle ne fonctionne toujours pas, suivez le lien pour une autre possibilité.
Michael Stimson

5

La seule fois où j'ai eu cela, c'est quand j'ai eu une autre instance ArcMap ouverte et j'ai oublié de la fermer avant de construire / déboguer. Si vous ne fermez pas toutes les instances à l'aide de l'assembly, l'ancienne continuera à être utilisée. Ou quelque chose comme ça.


J'ai essayé de redémarrer l'ordinateur ouvrant VS et d'exécuter le débogueur sans ouvrir aucune autre instance d'ArcMap. Il a lancé ArcMap comme d'habitude, mais le problème du «point d'arrêt mort» a persisté.
Jakub Sisak GeoGraphics

Je viens donc de configurer ArcGIS et Visual Studio sur une autre machine (toute installation propre) et la même chose a recommencé. J'ai essayé la suggestion de tout le monde et vous semblez avoir raison. Je me suis assuré de tuer tous les processus ArcGIS ouverts et lorsque je le fais, les points d'arrêt fonctionnent.
Jakub Sisak GeoGraphics

5

Comme .NET Framework de mon projet est 4.0, j'ai changé pour supportedRuntime version="v4.0.30319"dans ArcMap.exe.config et j'ai remarqué que le problème a été retardé par cette modification. Je me suis également souvenu qu'ArcMap charge également ArcCatalog, j'ai donc changé ArcCatalog.exe.config en supportedRuntime version="v4.0.30319"et OUI !!! Ça marche à nouveau. J'ai passé toute la journée à essayer de résoudre ce problème et j'espère que cela fonctionne aussi pour vous.


1
J'ai dû supprimer également les dossiers bin et obj.
Sabin Kolarov

4

J'ai essayé les suggestions ci-dessus pendant un certain temps et j'ai finalement trouvé une solution. Pour aller plus loin, je donnerai d'abord la solution, puis l'explication:

  1. Ouvrez le Gestionnaire des tâches. Terminez le processus pour toute copie d'ArcMap.exe.

  2. Ouvrez un explorateur Windows. Accédez à C: \ Users \\ Local Settings \ ESRI \ Desktop10 ..

  3. Si vous ne voyez pas AssemblyCache, Organisez> Dossier et options de recherche> Affichage> décochez "Masquer les fichiers protégés du système d'exploitation (recommandé)"

  4. Dans les répertoires de AssemblyCache, recherchez celui contenant votre .dll.

  5. Supprimez le .dll.

  6. Reconstruisez le projet et déboguez. Une fois votre complément activé, vous devriez voir le contenu du cache actualisé.

  7. Si vous le souhaitez, masquez à nouveau les fichiers protégés du système d'exploitation.

Le problème pour moi était qu'il y avait une ancienne instance de ma DLL dans le dossier C: \ Users \\ Local Settings \ ESRI \ DesktopX.X \ AssemblyCache \, et je ne pouvais pas non plus voir \ AssemblyCache parce que je ne savais pas c'était un fichier OS caché. Il y avait également une instance zombie d'ArcMap en cours d'exécution, et lorsque j'ai essayé de supprimer la DLL, elle était initialement verrouillée. Je soupçonne que ce qui a causé le problème en premier lieu, c'est que je n'ai pas complètement arrêté une session de débogage d'ArcMap avant de recompiler le code et d'en démarrer une autre. L'ancienne DLL du cache n'a pas pu être écrasée car l'ancienne instance d'ArcMap l'avait toujours verrouillée et une fois désynchronisée avec le nouveau code, la version mise en cache n'était plus mise à jour. (Je peux voir par date de fichier que les fichiers .config, .pdb et .xml sont mis à jour, mais pas le .dll.)


Oui, cela ressemble à la solution de contournement correcte.
Jakub Sisak GeoGraphics

2

Je faisais face au même problème, avec mon propre complément dans un tout autre sujet, et j'ai stigmatisé les éléments suivants:

Dans un premier temps, démarrez le débogage et dans le menu, choisissez la fenêtre suivante Debug >> Windows >> Modules, où vous pouvez voir quels modules ont été chargés au démarrage du débogage. Si vous ne pouvez pas voir le yourAddIn.dll, alors au moins vous savez qu'il n'a pas été chargé par le studio. Si vous y voyez et que vous ne pouvez pas y mettre le point d'arrêt, alors le Studio en a chargé un ancien. Pour vérifier cela, modifiez le nom de l'assembly dans les propriétés du projet, reconstruisez la solution, démarrez le débogage et vous verrez l'ancienne DLL chargée à cet endroit. Je ne sais pas d'où le studio charge cette ancienne DLL.

Accédez à l'Explorateur de solutions et vérifiez la comparaison des fichiers «yourAddIn.Addin» et «yourAddIn - For Testing.AddIn» et ils peuvent différer. Le studio utilise uniquement le 2ème fichier dans son gestionnaire de compléments! Au premier changement, modifiez également la balise pour vous référer à la bonne DLL et vous pouvez également vérifier la balise. Pour moi, le a été remis à 0 dans le fichier "yourAddIn - For Testing.AddIn", donc je l'ai changé à 1. (Si vous supprimez le répertoire bin de votre complément et démarrez le studio, il vous demandera et demandera qui souhaitez-vous supprimer ce complément de votre liste de compléments! À ce stade, le Studio définit le LoadBehavior à 0.)

Après ces deux changements, il a recommencé à fonctionner!


Merci de partager votre expérience et de prendre soin de nous fournir les détails. Bienvenue dans notre communauté!
whuber

2

Avec Visual Studio, j'ai créé un nouveau complément pour Arcmap, et y ai ajouté un bouton et une barre d'outils. Il en résulte un fichier de configuration ressemblant à ceci:

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

J'ai créé du code dans le constructeur du Button et y ai mis un point d'arrêt. J'ai commencé en mode débogage et je vois que l'assembly n'a pas encore été chargé:

entrez la description de l'image ici

J'ai changé le bouton pour inclure onDemand = false:

entrez la description de l'image ici

Quand j'ai recommencé arcmap, il a atteint le point de rupture. Notez que si la barre d'outils est désactivée au démarrage, vous devrez la rendre visible pour que le constructeur du bouton soit appelé - donc, à certains égards, il est toujours à la demande.


Merci @Kirk. Depuis que j'ai restauré mon projet à partir d'une sauvegarde, il semble fonctionner maintenant. Je débogue habituellement une procédure qui est plus loin sur la route; c'est à dire appelé du clic même d'un bouton ce qui était le cas cette fois. Je suis presque sûr que l'assemblage est déjà chargé à ce stade. (ou devrait l'être, mais ce n'est pas pour une raison quelconque) Je vais certainement essayer cette solution la prochaine fois que cela se produit.
Jakub Sisak GeoGraphics

2

J'ai dû changer mon addin pour arcCatalog pour qu'il corresponde à l'aide du framework 4 avec la nouvelle version 10.1 d'ArcCatalog.
Je viens de commenter la version = "v2.0.50727" et sans commentaires "v4.0.30319"

Dans C: \ Program Files (x86) \ ArcGIS \ Desktop10.1 \ bin, le fichier de configuration XML ArcCatlog.exe

s'arrête au point d'arrêt maintenant

Semble être le même problème avec arcmap


2

Après avoir migré un projet ESRI ArcGIS 10 d'une machine à l'autre, j'ai rencontré l'erreur selon laquelle la machine n'a pas pu charger les fichiers de débogage .pdb pour ArcMap.exe. J'ai essayé chaque conseil sur ce post sans aucune chance.

Ensuite, j'ai fait ce qui suit:

J'ai supprimé les références de toutes les bibliothèques Esri. * Dans chaque projet qui les contenait et les ai rajoutées au projet sur la nouvelle machine.

C'est ce qui a finalement fonctionné pour moi. Si quelqu'un bute ici avec ce problème vague et a essayé tout le reste répertorié sur cette page, essayez ceci - c'est rapide et facile et assez inoffensif. Je ne sais pas exactement pourquoi cela a dû être fait, je suppose que cela a à voir avec la recherche des bibliothèques par machine.

C'était pour un projet qui utilisait BaseCommands / Toolbars, et non les nouveaux compléments. Utilisation d'ArcGIS 10.0 et .NET 3.5 avec Visual Studio 2010 sur Windows 7 Pro.


2

Pour ceux qui ciblent le framework .Net 4.0, ce qui suit a fonctionné pour moi.

  1. Selon de nombreuses suggestions, modifiez ArcMap.exe.config et ArcCatalog.exe.config pour cibler le framework 4.0.
    <?xml version="1.0" encoding="utf-8" ?> <configuration> <startup> <supportedRuntime version="v4.0.30319"/> <!--supportedRuntime version="v2.0.50727"/--> </startup>
    Pour une raison quelconque, ArcCatalog.exe.config semble verrouillé pour modification. Je l'ai contourné en le copiant et en le modifiant dans un autre répertoire, puis en le remplaçant.
  2. Ensuite, dans Config.esriaddinx, changez la langue du complément en "CLR4.0"

1

Deux causes possibles me viennent à l'esprit:

  1. Le complément n'est pas enregistré correctement, de sorte que la DLL n'est pas chargée dans le processus ArcMap en cours de débogage.

  2. Votre projet cible .NET 4. Essayez plutôt de cibler .NET 3.5.


Ciblage .Net 3.5. Je ne comprends tout simplement pas pourquoi tout fonctionnerait bien et tout d'un coup pas.
Jakub Sisak GeoGraphics

1

Si vous codez avec plusieurs projets dans la même solution Visual Studio, vous pouvez rencontrer des situations où Visual Studio (VS) "désactive" vos points d'arrêt et vous ne pouvez pas parcourir votre code. Cela m'est arrivé récemment où je ne pouvais pas entrer dans un projet d'assemblage de DLL "dépendant" qui était appelé depuis mon projet principal.

Les avertissements VS suggéraient que mon assembly (DLL) était obsolète et ne correspondait pas exactement à mon code. Il existe des options VS pour désactiver l'exigence de correspondance du code, mais cela semblait intuitivement une mauvaise idée et a été sauvegardé par des publications Internet. J'ai lu de nombreux sites Web et il y a des suggestions noueuses là-bas.

À la fin, j'ai fait une recherche pour la DLL de sortie de ma machine dépendante et j'ai trouvé plusieurs anciennes copies à divers endroits sur mon ordinateur (probablement à partir d'expériences antérieures et de configurations de projet). Je les ai donc tous supprimés et reconstruit ma solution à partir de zéro. Cela a résolu mon problème. Je suppose que mon projet actuel était lié par inadvertance à l'une des anciennes copies et n'utilisait pas la dernière version qui était placée dans mon dossier de débogage.


1

Ce qui a fonctionné pour moi n'a pas été de supprimer l'arcmap.config.exe comme décrit dans l'article de Jakub ci-dessus, mais de définir la balise "supportedRuntime" dans ce fichier sur la version correcte du Framework que vous ciblez dans Visual Studio, dans mon cas:

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

1

Sur un certain nombre de projets ArcObjects, j'ai compilé une liste des raisons pour lesquelles le débogage peut ne pas fonctionner pour les compléments, extensions et commandes (pré-complément). Dans aucun ordre particulier:

  1. Vous êtes en mode Release de Visual Studio au lieu du mode Debug
  2. Les anciennes versions de l'outil sont toujours enregistrées auprès d'ArcMap / ArcCatalog et celles-ci empêchent le chargement de votre version de débogage, ou d'autres outils du même nom sont enregistrés
  3. Le projet / la solution doit être nettoyé, et si nécessaire, allez dans \ bin et \ obj et supprimez tous les fichiers en attente
  4. Dans certains cas, les points d'arrêt ne peuvent être atteints qu'après l'activation de l'outil (à la demande)
  5. Si aucun point d'arrêt n'est atteint, il est possible qu'une exception se produise dans le constructeur et que l'outil ne s'exécute jamais. Vérifiez en affichant toutes les exceptions CLR dans le menu de débogage
  6. Les entrées dans C: \ Users \ <nom> \ Paramètres locaux \ ESRI \ DesktopX.X \ AssemblyCache doivent être supprimées

De nombreuses étapes nécessitent le redémarrage d'ArcMap. Si tout le reste échoue, le redémarrage de la machine est une solution de rechange facile, mais je n'ai eu qu'une seule fois cela fait une différence.



0

J'ai eu ça une ou deux fois. Si je me souviens bien, j'ai réussi à faire fonctionner le point d'arrêt lorsque j'ai apporté une modification mineure au code, ce qui signifie que l'application a été reconstruite. Que se passe-t-il lorsque vous construisez ou reconstruisez votre projet?


J'ai essayé de reconstruire le projet et j'ai fait plusieurs changements mais les points d'arrêt étaient toujours "morts" ...
Jakub Sisak GeoGraphics

0

Je ne peux pas croire que plus de gens n'aient pas ce problème. Je rencontre maintenant presque chaque fois que j'améliore et débogue mes compléments.

Aucune des solutions mentionnées ci-dessus ne fonctionne. Pour résoudre ce problème, je dois supprimer l'intégralité du projet et le restaurer à partir de la sauvegarde. Cela m'amène à croire que quelque chose dans le projet particulier est devenu corrompu car il se produit généralement lorsque ArcMap se bloque pendant le débogage.


Existe-t-il des processus ArcMap.exe persistants? Parfois, les compléments, extensions, commandes, etc. peuvent conserver une ressource ou provoquer une condition de concurrence critique qui empêche ArcMap de se fermer complètement.
blah238

Aucun processus ArcMap.exe n'est en cours d'exécution. J'ai maintenant une réponse du personnel d'ESRI pour essayer de supprimer <supportedRuntime version = "v2.0.50727" /> de arcmap.exe.config, dans le répertoire bin. Cependant, je ne sais pas d'où je supprime cet élément et je viens de restaurer mon projet à partir de la sauvegarde et il fonctionne maintenant. Lorsque j'en saurai plus sur ce correctif, je planterai ArcMap pendant le débogage, ce qui rend généralement cela possible et je l'essayerai.
Jakub Sisak GeoGraphics,

0

Créez-vous votre projet en utilisant Framework 4? J'ai eu le même problème, mais lorsque je passe au Framework 3.5, cela fonctionne bien.


0

essayez de nettoyer et de reconstruire puis exécutez sans débogage, lorsque l'application s'exécute, attachez-la dans VS


0

Je sais que cela peut sembler trop évident, mais je le mentionnerai quand même, c'est que vous avez besoin de l'édition appropriée de Visual Studio. Par exemple, ce problème peut se produire avec une édition express d'une année donnée alors qu'il peut fonctionner avec une édition ultime. Si vous utilisez par exemple 2010, essayez de passer à 2012. Ensuite, essayez de passer de l'express à l'ultime. Je le ferais si vous ne l'avez pas déjà fait avant de jouer avec les problèmes de chargement de symboles. ESRI fournit des informations sur le téléchargement des symboles dans le cache, comme indiqué dans le lien ci-dessus (Aide du SDK ArcObjects 10 .NET). Cependant, cela peut ne pas être nécessaire. Assurez-vous que vous utilisez le framework .net approprié également avant le débogage, par exemple .net 3.5 sur les anciennes éditions.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.