web-dev-qa-db-fra.com

Les points d'arrêt Visual Studio séparent le fichier source incorrect (ou plusieurs fichiers simultanément) si plusieurs fichiers portent le même nom.

Dans un projet d'équipe sur lequel je travaille, la définition d'un point d'arrêt dans un fichier (par exemple, IdeasController.cs) entraînera un comportement irrégulier du débogueur s'il existe un autre fichier du même nom dans la solution. J'ai reproduit le problème sur plusieurs postes de travail de développeurs.

Exemple

J'ai défini un point d'arrêt dans IdeasController.cs dans notre API Web:

Breakpoint set in code

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

Debugger highlight does not match code structure

La fenêtre Point d'arrêt affiche le point d'arrêt dans les deux fichiers simultanément:

Breakpoint spans both files

Sur certains postes de travail, le débogueur parcourt les lignes correctes (quelle que soit la surbrillance de la ligne). sur d'autres, il parcourt joyeusement des lignes non pertinentes (y compris des commentaires et des espaces). Je suppose que cela dépend du fichier source qu’il choisit d’afficher.

Ce que j'ai essayé

J'ai parcouru l'Internet. Ce type de problème semble se produire en cas d'incompatibilité 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 en double (qui peuvent perturber le débogueur[5]), des fichiers de génération de projet obsolètes, un cache de solution non valide ou une configuration de construction incorrecte.

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

  • Vérifié ma configuration de construction.
    1. Assurez-vous que le projet n'est pas construit en mode release.
    2. Assurez-vous que nous n'avons pas l'optimisation du code activée .
    3. Assurez-vous que le module de débogage du projet a été chargé correctement. (Débogage du projet et vérification de Debug> Windows> Modules. Les deux assemblys sont répertoriés, pas optimisés et ont le statut de symbole "Symboles chargés".)
  • Réinitialisez les métadonnées de débogage et le cache de Visual Studio.
    1. Fermez Visual Studio et supprimez le fichier de cache de la solution (*.suo).[1]
    2. Supprimez la sortie de génération de chaque projet (les dossiers bin et obj). (Pour référence future: ouvrez le dossier de la solution dans l'Explorateur Windows et tapez-le dans le champ de recherche: "type:folder AND (name:=bin OR name:=obj)".
    3. Supprimé le dossier de cache d'assemblage (C:\Documents and Settings\<user>\Local Settings\Application Data\dl3).[2][3]

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

Où je suis maintenant

Page 14 de ma dernière recherche sur Google. Des suggestions seraient très appréciées. :)

visual-studiodebuggingmsbuildvisual-studio-2012debug-symbols
42
Pathoschild

Je suis tellement content d'avoir trouvé ce post, pensant que j'étais le seul et que je devenais fou! J'ai le même problème dans VS2012 avec VB.Net et j'ai tout essayé dans l'OP mentionné.

La dénomination unique des fichiers semble être le seul correctif à 100% que j'ai trouvé. Désactiver tous les points d'arrêt jusqu'au chargement de l'application, puis réactiver les points d'arrêt dont vous avez besoin fonctionne la plupart du temps. Les points d'arrêt dans les fonctions Lambda peuvent toujours vous donner des problèmes.

6
Miiir

Je viens d'avoir exactement le même problème. Ce qui a résolu le problème pour moi, c’est de supprimer les fichiers .suo de la solution contenant le fichier projet/source concerné.

J'ai également supprimé mon symbolcache local, mais je ne pense pas que cela y soit pour quelque chose.

(Ma solution contient plusieurs projets, un fichier (DataAdapter.cs) dans un projet était affecté (VisualStudio a placé mes points d'arrêt dans la pdb appartenant à System.Data.DataAdapter). J'ai ouvert le fichier .csproj directement et j'ai pu correctement définir le point d'arrêt.)

4
Steffen Winkler

S'il n'y a pas de meilleures alternatives, vous pouvez mettre le point d'arrêt dans le code:

System.Diagnostics.Debugger.Break();

N'oubliez pas de l'enlever ensuite ...

4
bdrajer

J'ai eu le même problème aujourd'hui. J'ai été en mesure de remonter au fait que j'avais oublié de définir la cible de la plate-forme sur x86 lors du débogage. Malheureusement, les autres (x64/Any CPU) peuvent poser problème 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.

Certaines spéculations ... Je pense que le débogueur (lors de l'exécution d'une application 64 bits) "vole" en quelque sorte les points d'arrêt d'un fichier dans certains cas. Pour moi, c’est parce qu’une autre assemblée, chargée du même nom de fichier, a été chargée en premier. J'ai pu éviter le problème, même en mode 64 bits, si j'avais d'abord chargé manuellement l'Assemblée avec mes points d'arrêt: Assembly.Load ("MyAssemblyWithBreakpoints");

J'espère que cela (ma première contribution stackoverflow) peut aider.

3
David Beavon

Je viens d'avoir ce problème sur Visual Studio 2017 (version 15.9.7), où les points de rupture ont été ignorés et le débogueur a "sauté" sur les instructions de retour, etc.

Après un certain temps, j'ai remarqué que j'avais récemment ajouté un fichier .runsettings au projet - et il s'est avéré que dans mon cas, la configuration du collecteur de données CodeCoverage était à l'origine de ce problème. Dès que j'ai supprimé cette section:

<DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"> ... </DataCollector>

à partir du fichier .runsettings, cela a fonctionné à nouveau comme un charme.

2
DSpirit

Je viens de sauvegarder et de supprimer le fichier puis de le rajouter au projet, ce qui a résolu le problème. Je souhaite juste l'avoir fait avant de parcourir la liste mentionnée plus haut :)

1
Jan Lecko

J'avais ce problème dans Visual Studio 2015.

J'avais un sous-dossier avec un DLL que je voulais enregistrer en tant que Version1. Il semble que même après avoir supprimé la référence à cette DLL, puis ajouté une référence à un autre studio de projet, la référence existante a été insérée et le fichier source erroné a été inséré. J'ai supprimé cette DLL dans le sous-dossier, puis Studio a obtenu la source correcte.

J'ai trouvé un lien utile sur [MSDN qui montre comment effacer les fichiers source précédemment associés en studio via ce lien] [1].

Résumé:

  1. Dans l’explorateur de solutions, cliquez avec le bouton droit sur le nom de la solution (ex: Solution ‘TestApplication’) et sélectionnez Propriétés. La boîte de dialogue Pages de propriétés de la solution apparaît.
  2. Sous Propriétés communes, sélectionnez Fichiers sources de débogage.
  3. Dans la zone Rechercher dans ces chemins les fichiers de code source (Visual Studio .NET 2003)/Répertoires contenant le code source (Visual Studio 2005), ajoutez, supprimez et/ou réorganisez les répertoires comme vous le souhaitez.
  4. Cliquez sur le bouton OK
1
Patrick

Bien que renommer l’un des fichiers fonctionne, j’ai trouvé que la solution la plus simple consiste à désactiver temporairement le chargement automatique des symboles de l’autre «autre» Assemblée.

  1. Démarrez le débogueur et continuez jusqu'à ce que vous atteigniez le point d'arrêt erroné.
  2. Recherchez où le débogueur en fait définissez le point d'arrêt à l'aide de la fenêtre Call Stack :
    1. Cliquez avec le bouton droit sur la ligne avec la flèche jaune et activez Afficher les noms des modules . (La ligne doit également comporter le symbole de point d'arrêt rouge.)
    2. Le nom de l'assembly est maintenant visible sur cette ligne.
  3. Recherchez cet assemblage dans la fenêtre Modules ( Debug> Windows> Modules ).
  4. Cliquez avec le bouton droit sur l'assemblage et désactivez Toujours charger automatiquement .
  5. Arrêtez le débogueur. 
  6. Recommencez le débogage.

Ainsi, vous empêchez le débogueur Visual Studio de mapper le point d'arrêt sur le mauvais assembly. Il chargera ensuite les symboles de l'autre [vraisemblablement] bon assembleur en premier, mappant ainsi le point d'arrêt au bon assemblage.

Pourquoi cela arrive-t-il?

Cela semble se produire lorsque deux fichiers de symboles différents (fichiers PDB) - pour deux assemblys différents - font tous deux 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 avoir été confondu.

Par exemple, imaginons qu'il existe deux fichiers différents portant le nom IdeasController.cs. Le premier compile dans Assembly Api.dll, et le second dans Assembly Web.dll. 

Lorsque le débogueur charge des symboles, il charge d'abord Api.pdb ou Web.pdb. Disons que cela charge Api.pdb en premier. Ensuite, même si vous définissez un point d'arrêt dans Web\IdeasController.cs, une correspondance sera trouvée pour IdeasController.cs dans Api.pdb. Il mappe ensuite le code de Web\IdeasController.cs à Api.dll. Cela ne mappera pas correctement, bien sûr, et vous verrez toutes sortes de problèmes étranges lors du débogage.

1
Malarial

J'ai eu un problème très similaire. Dans mon cas, le problème était lié à un framework .net cible différent dans l'un des projets, ce qui entraînait le chargement incorrect par VS2017 d'un fichier source (portant le même nom) d'un autre projet, et non celui activé par

ObjectHandle handle = Activator.CreateInstance

Changer le cadre cible du projet pour qu'il soit identique dans tous les projets l'a corrigé.

0
Stefan Michev

Supprimez tous les fichiers .pdb du projet où le point d'arrêt frappe à tort. Cela résoudra le problème.

0
Ramaraj K

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

J'ai remarqué que j'avais dupliqué des fichiers .dll dans mes dossiers de projet, et résolu de supprimer le .dlldupliqué, tout en ne conservant qu'un .dll par nom dans la structure du dossier de débogage. (Par exemple, dans mon cas, /bin/Example.dll et /bin/Plug-in/Example.dll étaient présents sous la structure de mon dossier de débogage).

0
Simone

Ce qui a fonctionné pour moi (VS2017) a été désactivation cette option dans Tools --> Options... --> Debugging --> General: " Les fichiers sources doivent correspondre exactement à la version originale ", activée par défaut, mais je l’avais activée.

Cela ne suffisait cependant pas, j'ai également dû supprimer manuellement les dossiers obj et bin pour tous les projets de la solution. 

0
batintherain

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

0
Diogo