Les points de rupture de Visual Studio cassent le mauvais fichier source (ou plusieurs fichiers simultanément) si plusieurs fichiers ont le même nom

dans un projet d'équipe sur lequel je travaille, la mise en place d'un point de rupture dans un fichier (disons IdeasController.cs ) entraînera un comportement erratique de débogueur s'il y a un autre fichier du même nom dans la solution. J'ai reproduit le problème sur plusieurs développeurs postes de travail.

exemple

j'ai défini un point de rupture dans IdeasController.cs dans notre API Web:

Breakpoint set in code

un autre fichier appelé IdeasController.cs existe dans notre projet web distinct MVC 4. Dans la capture d'écran ci-dessous, le débogueur affiche le code source Api->IdeasController , mais la ligne en surbrillance correspond à la structure du code de Web->IdeasController . Le point d'arrêt est reproduit, avec l'un d'eux, au milieu d'un bloc de commentaire.

Debugger highlight does not match code structure

la fenêtre du point de rupture affiche le point de rupture dans les deux fichiers simultanément:

Breakpoint spans both files

sur certains postes de travail, le débogueur passe par les lignes correctes (indépendamment de la mise en évidence de la ligne); sur d'autres, il passe joyeusement par des lignes non pertinentes (y compris les commentaires et les espaces). Je suppose que cela dépend du fichier source qu'il choisit d'afficher.

ce que j'ai essayé

j'ai traqué le Internet. Ce genre de problème semble se produire lorsqu'il y a un décalage entre le fichier de débogage ( *.pdb ), le fichier source et le code compilé. Il y a beaucoup de causes possibles: les noms de fichiers dupliqués (qui peuvent embrouiller le débogueur) [5] ), des fichiers de construction de projet périmés, un cache de solution invalide ou une configuration de construction incorrecte.

ce sont les solutions que j'ai trouvées et essayées:

  • a vérifié ma configuration de construction.
    1. a fait en sorte que le projet n'est pas construit en mode de version.
    2. S'est assuré que n'ont pas l'optimisation de code activé .
    3. S'est assuré que le module de débogage du projet était chargé correctement. (Commencé à déboguer le projet et vérifié Debug > Windows > Modules . Les deux ensembles sont listés, non optimisés, et ont un statut de symbole de "symboles chargés".)
  • Réinitialiser le débogage des métadonnées et Visual Studio cache.
    1. a fermé Visual Studio et supprimé le fichier de cache solution ( *.suo ). [1]
    2. supprimait la sortie de construction de chaque projet (les dossiers bin et obj ). (Pour référence future: ouvrez le dossier solution dans Windows Explorer et tapez ceci dans la boîte de recherche: " type:folder AND (name:=bin OR name:=obj) ".
    3. a supprimé le dossier cache d'assemblage ( C:Documents and Settings<user>Local SettingsApplication Datadl3 ). [2] [3]

aucun de ceux-ci n'a eu d'effet. Je peux renommer les fichiers (sans le renommer la classe) pour contourner temporairement ce problème, mais c'est loin d'être idéale.

où je suis maintenant

Page 14 ma dernière recherche sur Google. Les Suggestions seraient grandement appréciées. :)

39
demandé sur Pathoschild 2012-09-14 03:25:29

11 réponses

je suis tellement heureux que j'ai trouvé ce post, pensé que j'étais le seul et était en train de devenir folle! J'ai le même problème en VS2012 avec VB.Net et j'ai essayé tout ce que L'OP a mentionné.

la dénomination Unique des fichiers semble être la seule solution à 100% que j'ai trouvée. Désactiver tous les points d'arrêt jusqu'à ce que l'application soit chargée et ensuite réactiver les points d'arrêt dont vous avez besoin fonctionne la plupart du temps. Les points de rupture dans les fonctions Lambda peuvent encore vous donner des problèmes.

5
répondu Miiir 2014-05-15 14:28:19

S'il n'existe pas de meilleure alternative, vous pouvez mettre le point de rupture en code:

System.Diagnostics.Debugger.Break();

N'oubliez pas de l'enlever après...

4
répondu bdrajer 2014-08-01 08:50:30

j'ai eu le même problème aujourd'hui. J'ai pu remonter jusqu'au fait que j'avais oublié de définir la cible de la plate-forme à x86 pendant le débogage. Malheureusement les autres (x64 / N'importe quel CPU) peuvent être problématiques lors du débogage. Au moins VS 2008 ne les aime pas. Je suppose que c'est encore une autre raison de rester à l'écart.

quelques spéculations... Je pense que le débogueur (alors qu'il exécute une application 64 bits) "vole" en quelque sorte les points de rupture d'un fichier dans certains cas. Pour moi, c'était parce qu'une autre assemblée a été chargée en premier qui avait le même nom de fichier. J'ai pu éviter le problème, même en mode 64 bits, en chargeant manuellement l'ensemble avec mes points de rupture: Assembly.Charge ("MyAssemblyWithBreakpoints");

J'espère que ceci (ma première contribution à stackoverflow) vous aidera.

3
répondu David Beavon 2013-04-04 22:11:48

j'ai eu exactement le même problème. Ce qui l'a résolu pour moi, c'est la suppression de la .fichiers suo appartenant à la solution qui contenait le projet/fichier source concerné.

j'ai aussi supprimé mon symbole local, mais je ne pense pas que cela ait quelque chose à voir avec ça.

(ma solution contient plusieurs projets, un fichier (DataAdapter.cs) dans un projet a été affectée par cela (VisualStudio mis mes points de rupture dans l'APB appartenant à Système.Données.Dataaadapter). J'ai ouvert la .csproj le fichier directement et a été en mesure de définir correctement le point de rupture.)

3
répondu Steffen Winkler 2015-07-01 09:19:37

j'ai juste sauvegardé et supprimé le fichier et ensuite ajouté de nouveau au projet, qui a résolu le problème. Je viens qui je l'ai fait avant d'aller à travers les cités de la liste :)

1
répondu Jan Lecko 2013-09-17 10:12:32

je faisais ce numéro dans Visual Studio 2015.

j'avais un sous-dossier avec une DLL que je voulais enregistrer sous Version1. Il semble même après avoir supprimé la référence à cette DLL, puis Ajouter une référence à un autre studio de projet tiré dans la référence existante et est allé au mauvais fichier source. J'ai enlevé cette DLL dans le sous-dossier, puis Studio a eu la bonne source.

j'ai trouvé un lien utile sur [MSDN qui montre comment fichiers sources associés dans studio à ce lien][1].

résumé:

  1. dans L'Explorateur de solutions, cliquez avec le bouton droit de la souris sur le nom de la solution (ex: solution ‘Testamlication’) et sélectionnez Propriétés."
  2. sous Propriétés communes, sélectionnez Debug Source Files
  3. dans la recherche de ces chemins pour les fichiers de code source (Visual Studio. net 2003) / Répertoires contenant le code source (Visual Studio 2005), d'ajouter, de supprimer et/ou réordonner les répertoires désirés
  4. cliquez sur le bouton OK
1
répondu Patrick 2016-09-09 14:52:17

vous pouvez également essayer de nettoyer et de reconstruire (pas construire) tous les projets.

0
répondu Diogo 2016-09-01 20:08:25

bien que renommer l'un des fichiers fonctionne, j'ai trouvé que la solution la plus simple est de désactiver temporairement le chargement automatique des symboles pour l'ensemble" other".

  1. démarrez le débogueur et continuez jusqu'à atteindre le point de rupture erroné.
  2. trouver où le débogueur en fait définir le point de rupture en utilisant le pile D'appels fenêtre:
    1. clic droit sur la ligne avec la flèche jaune et activer afficher les noms de modules . (La rangée doit aussi porter le symbole du point de rupture rouge.)
    2. le nom de l'assemblée est maintenant visible sur cette rangée.
  3. trouver cet assemblage dans la fenêtre des Modules ( Debug > Windows > Modules ).
  4. faites un clic droit sur l'ensemble et désactivez chargez toujours automatiquement .
  5. arrêtez le débogueur.
  6. redémarrez le débogage.

en faisant cela, vous empêchez le débogueur Visual Studio de mapper le point de rupture vers le mauvais assemblage. Il chargera ensuite les symboles de l'autre [présumément] ensemble correct d'abord, donc la correspondance du point de rupture à l'ensemble correct.

pourquoi cela arrive-t-il?

cela semble se produit lorsque deux fichiers de symboles différents (fichiers PDB) - pour deux assemblages différents - font référence à un fichier source portant le même nom. Bien que les fichiers source soient complètement différents, le débogueur Visual Studio semble être confus.

par exemple, imaginez qu'il y ait deux fichiers différents avec le nom IdeasController.cs . La première se compile en assemblée Api.dll , et la seconde se compile en assemblée Web.dll .

quand le débogueur charge les symboles, il chargera Api.pdb ou Web.pdb en premier. Disons qu'il charge Api.pdb d'abord. Puis même si vous définissez un point de rupture dans Web\IdeasController.cs , il trouvera une correspondance pour IdeasController.cs dans Api.pdb . Il fait ensuite correspondre le code de Web\IdeasController.cs à Api.dll . Cela ne se passera pas correctement, bien sûr, et donc vous voyez toutes sortes de problèmes étranges pendant le débogage.

0
répondu Malarial 2017-03-31 22:23:41

ce qui a fonctionné pour moi (VS2017) était désactiver cette option dans Tools --> Options... --> Debugging --> General : " nécessitent des fichiers sources pour correspondre exactement à la version originale ", qui est activé par défaut mais je l'ai fait allumer.

ce n'était pas suffisant cependant, j'ai aussi dû enlever manuellement les dossiers obj et bin pour tous les projets en solution.

0
répondu batintherain 2017-11-20 10:02:06

supprimer tous les .les fichiers de l'APB du projet où le point de rupture frappe à tort. Cela permettra de résoudre le problème.

0
répondu Ramaraj K 2018-02-15 11:59:47

Il m'est arrivé (dans VS 2008 ) d'avoir deux enfants de point d'arrêt avec le même adresse mémoire et le même fichier associé . Ces points de rupture ont été produits à un certain moment pendant le déroulement du processus.

j'ai remarqué que j'avais dupliqué des fichiers .dll dans Mes dossiers de projet, et j'ai résolu de supprimer le .dll dupliqué , tout en ne conservant qu'un seul .dll par nom dans la structure du dossier de débogage. (Comme exemple dans mon cas j'ai eu /bin/Example.dll et /bin/Plug-in/Example.dll tous les deux présents sous ma structure de dossier de débogage).

0
répondu Simone 2018-04-27 13:30:21