.net - will - le point d'arrêt ne sera pas atteint pour l'instant. aucun symbole n'a été chargé pour ce document




"Le point d'arrêt ne sera pas actuellement touché. Le code source est différent de la version originale. "Qu'est-ce que cela signifie? (20)

Lors du débogage dans Visual Studio, parfois j'ajoute un point d'arrêt mais c'est creux et VS dit "Le point d'arrêt ne sera pas touché actuellement, le code source est différent de la version originale." Évidemment, cela m'empêche de pouvoir déboguer.

Que diable signifie le message? Quelle version originale? Si je viens d'ouvrir la solution et que je n'ai apporté aucune modification au code, comment peut-il y avoir une 'version originale'?


Aller à

  • Outils
    • Options
      • Débogage
        • Général

Décochez Exiger les fichiers sources pour qu'ils correspondent exactement à la version d'origine


Avez-vous déjà fait ça?

Souhaitez-vous continuer et exécuter la dernière version réussie?

Si vous avez coché la case et appuyé sur "Oui", vous obtiendrez la dernière version réussie même si votre projet ne compile pas. Cela signifie que chaque fois que vous définissez un point d'arrêt, vous obtiendrez cette erreur.

Essayez de changer cette valeur:

  • Outils
    • Options
      • Projets et solutions
        • Construire et exécuter
          • En cours d'exécution, lorsque des erreurs de génération ou de déploiement se produisent: Ne pas lancer

Cela arrive aussi lors du débogage d'un projet C ++ qui charge un module qui a été implémenté avec un langage CRL (Managed C ++, C # etc). Dans cette situation, le message d'erreur est en effet trompeur.

La solution consiste à mettre la propriété de configuration du support Common Language Runtime (CLR) dans le projet de démarrage et à la recompiler.


Cela arrive souvent aussi si vous utilisez des références de fichiers aux binaires (au lieu des références de projet au code dans votre projet), et que le binaire compilé que vous référencez n'est pas synchronisé avec le code source correspondant sur votre machine. Cela peut arriver parce que vous avez téléchargé une nouvelle version du binaire du contrôle source sans le nouveau code source qui l'accompagne, ou vous avez quelques versions du binaire sur votre machine et référençant une ancienne copie, etc. le problème, c'est une bonne raison d'utiliser autant que possible les références de projets.


Comme il est dit, le "code source est différent de la version originale".

Faites un clic droit sur le dossier du projet dans l'explorateur de solution et choisissez Clean . Construisez une nouvelle version du projet et le point d'arrêt fonctionnera à nouveau!


Dans mon cas, je développais une application Windows CE, qui testait contre un émulateur. Le problème était que l'exécutable n'était pas déployé sur l'émulateur, donc le fichier .pdb (dans l'environnement de développement) n'était pas synchronisé avec le fichier .exe (dans l'émulateur), car le nouveau fichier .exe n'était jamais copié dans l'émulateur. J'ai dû supprimer le fichier .exe dans l'émulateur pour forcer un nouveau déploiement. Alors ça a marché.


Essayez de désactiver et de redéfinir le point d'arrêt en cours d'exécution en mode débogage au lieu de le faire avant de lancer le mode débogage.


Faites attention à la fenêtre "Sortie" dans VS. Il vous dira quels assemblages sont chargés et quand. Vous pouvez voir qu'une ancienne version de votre assembly quelque part dans le dossier est en cours de chargement.

Par exemple, si vous avez plusieurs assemblages et que vous essayez actuellement de rompre dans l'un des assemblys de support, le CLR gérera la résolution de l'assemblage, qui peut charger un autre fichier d'assemblage que celui que vous avez référencé dans le projet.


J'ai été sur Visual Studio 2017 après avoir ajouté des fichiers existants au projet. Cela a fonctionné pour moi:

  1. fermez la solution,
  2. allez dans le SolutionFolder\.vs\SolutionName\v15\sqlite3 et supprimez storage.ide
  3. ouvrez à nouveau la solution

J'ai d'abord essayé à partir de la ligne de commande;

la suppression des fichiers temporaires de la ligne de commande a fonctionné.

C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Fichiers ASP.NET temporaires> racine rd / s

Lorsque je désactive l' option "Activer juste mon code" dans Outils -> Options -> Débogage -> Général

Le problème résolu pour moi. C'est une application WCF, essayait de déboguer une page ashx. http://blogs.msdn.com/b/zainnab/archive/2010/10/25/understanding-just-my-code.aspx


J'ai vécu cela dans une version 32 bits sur vs2017.

Exactement aucune des solutions n'a fonctionné pour moi. J'ai redémarré, j'ai effacé les fichiers IDE, nettoyé la solution construite, tiré de git repo et reconstruit la solution en vain.

J'utilisais une dépendance 64 bits de nuget et dès que j'utilisais l'assemblage, les sources n'étaient plus intégrées dans l'exécutable final et les sources en cache de l'IDE étaient en cours de construction.

J'ai supprimé la configuration de nuget, supprimé l'assembly référencé, téléchargé la source, construit manuellement log4net, l'ai signé, l'ai ajouté à un dossier dans mon projet, ajouté une référence à celui-ci, et j'ai pu déboguer à nouveau.

Ça a été une douleur, j'espère que ça se lève dans la liste des réponses pour que tout le monde puisse voir.

Edit: Il n'y a pas eu d'erreur lors de la construction même si l'option "prompt on build error" a été activée dans les paramètres de l'EDI.


La fermeture de Visual Studio et la réouverture de la solution peuvent résoudre le problème, c'est-à-dire que c'est un bogue dans l'EDI lui-même (je cours VS2010).

Si vous avez plusieurs instances de Visual Studio en cours d'exécution, vous devez seulement fermer l'instance exécutant la solution avec le problème.


Pour moi, aucun des éléments n'a résolu le problème. Je viens d'ajouter une nouvelle ligne de code dans cette fonction, quelque chose comme:

int a=0;

en ajoutant cela, je suppose que j'ai déclenché Visual Studio pour ajouter cette fonction à la version originale


Pour moi, c'était en travaillant sur un projet WebSite. Après avoir nettoyé ces dossiers temporaires, j'ai récupéré les erreurs correctes du compilateur:

  • C:\Documents and Settings\%username%\AppData\Local\Temp\Temporary ASP.NET Files
  • C:\windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files

J'ai finalement résolu le problème quand j'ai découvert qu'un fichier de classe que j'avais intentionnellement déplacé dans un sous-dossier, réapparaissait en quelque sorte dans le dossier racine. VS utilisait celui-là pendant que j'éditais l'autre.


Sélectionnez Déboguer dans les configurations de solution , au lieu de la version


Si votre processus débogué contient plusieurs domaines d'application et que l'assembly est chargé dans les deux, et que l'un d'entre eux charge une ancienne copie (généralement quelque chose chargé dynamiquement comme un plugin), le point d'arrêt peut apparaître solide. appdomain avec l'ancien assembly, et ne frappe jamais. Vous pouvez voir quels assemblages sont chargés et leur chemin dans la fenêtre du module.


Sous Windows 7, Visual Studio Express 2010, si vous avez activé l'option Utiliser le mode de compatibilité pour Windows XP SP3 , cette erreur peut se produire.

J'ai décoché l'option et cela a fonctionné à nouveau parfaitement. Cliquez avec le bouton droit sur le raccourci vers VS ou l'exécutable, sélectionnez les propriétés , puis la compatibilité .


Une nouvelle façon d'obtenir ce problème est apparue à partir de Visual Studio 2017 15.3.1 à 15.3.5. Si vous utilisez EditorConfig , l'option charset=utf8 provoque ces symptômes. L'équipe VS a reproduit cela et dit qu'ils travaillent dessus .

Donc, une solution est de commenter votre ligne charset=utf8 dans le fichier .editorconfig.

Edit: Ceci devrait être corrigé à partir de VS 15.5.


Vous pouvez obtenir ce message lorsque vous utilisez un activateur et que l'assembly dans lequel vous avez défini le point d'arrêt n'a pas encore été chargé.

Le point d'arrêt se résoudra une fois que l'activateur aura chargé l'assemblage (en supposant que les symboles d'assemblage et de débogage sont à jour). Un bon endroit pour regarder est la fenêtre des modules dans le menu de débogage. Là, vous devriez chercher l'assemblage auquel appartient votre fichier. Vérifiez d'abord que l'assemblage est chargé. Ensuite, d'où est-il chargé? Ensuite, le fichier de symboles est chargé. Encore une fois, d'où vient le fichier de symboles? Enfin, vérifiez les versions des deux.


aller à: tools -> options -> Debugging -> Général et décoché "Exiger que les fichiers source correspondent exactement à la version originale"





debugging