«Le point d'arrêt ne sera pas atteint actuellement. Le code source est différent de la version originale. " Qu'est-ce que ça veut dire?

Lors du débogage dans Visual Studio, parfois j'ajoute un point d'arrêt mais il est creux et VS dit "Le point d'arrêt ne sera pas actuellement atteint. Le code source est différent de la version d'origine." É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»?

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

Cliquez avec le bouton droit sur le dossier du projet dans l'explorateur de solutions et choisissez Clean. Créez une nouvelle version du projet et le point d'arrêt fonctionnera à nouveau!

Si vous avez décoché le projet DLL dans la configuration de construction de débogage , votre nouveau code ne sera jamais généré!

Accédez à Build --> Configuration Manager ...(dans VS2010) et vérifiez si le projet avec le code que vous essayez de déboguer est vérifié pour la configuration de construction actuelle.

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

• 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 lorsque 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.

L'avez-vous déjà fait?

Voulez-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 génération réussie, même si votre projet ne se compile pas. Cela signifie que chaque fois que vous définissez un point d'arrêt, vous obtiendrez cette erreur.

Essayez de modifier cette valeur:

• Outils
  • Les options
    • Projets et solutions
      • Construire et exécuter
        • Lors de l'exécution, lorsque des erreurs de génération ou de déploiement se produisent: ne pas lancer

Aller à

• Outils
  • Les options
    • Débogage
      • Général

Décochez Exiger que les fichiers source correspondent exactement à la version d'origine

Sélectionnez Debug dans les configurations de solution , au lieu de Release

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 disposez de plusieurs assemblys et que vous essayez actuellement d'interrompre l'un des assemblys de support, le CLR gère la résolution de l'assembly, qui peut charger un autre fichier d'assembly que celui que vous avez référencé dans le projet.

La fermeture de Visual Studio et la réouverture de la solution peuvent résoudre le problème, c'est-à-dire qu'il s'agit d'un bogue dans l'IDE lui-même (j'exécute VS2010).

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

Une nouvelle façon de résoudre ce problème est apparue à partir de Visual Studio 2017 15.3.1 à 15.3.5. Si vous utilisez EditorConfig , l' charset=utf8option provoque ces symptômes. L'équipe VS a reproduit cela et dit qu'elle y travaille .

Une solution consiste donc à mettre en commentaire votre charset=utf8ligne dans le fichier .editorconfig.

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

Cela se produit souvent également si vous utilisez un fichier de références à des fichiers binaires (au lieu de références de projet à du code dans votre projet), et que le binaire compilé auquel vous faites référence n'est pas synchronisé avec le code source correspondant sur votre machine. Cela peut se produire parce que vous avez téléchargé une nouvelle version du binaire à partir du contrôle de code source sans le nouveau code source qui l'accompagnait, ou que vous avez quelques versions du fichier binaire sur votre machine et que vous faites référence à une ancienne copie, etc. Si c'est effectivement le cas le problème, c'est une bonne raison d'utiliser autant que possible les références de projet.

Pour moi, aucun des éléments n'a résolu le problème. Je viens d'ajouter une nouvelle ligne de code à l'intérieur de 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

Cela peut se produire lorsque l'heure du système change pendant le débogage ou entre les sessions de débogage, que ce soit par programme, manuellement ou par un programme externe.

Il y a un paramètre presque imperceptible qui a résolu ce problème pour moi. S'il existe un fichier source particulier dans lequel le point d'arrêt ne frappe pas, il peut être répertorié dans

• Explorateur de solution
  • Solution de clic droit
    • Propriétés
      • Propriétés communes
        • Déboguer les fichiers source
          • Msgstr "Ne cherchez pas ces fichiers sources".

Pour une raison inconnue de moi, VS 2013 a décidé d'y placer un fichier source, et par la suite, je n'ai plus pu atteindre le point d'arrêt dans ce fichier. Cela peut être la cause du "code source différent de la version d'origine".

Le problème est que vos informations de débogage ne sont pas synchronisées avec votre assembly. La solution est simple:

1. Accédez à votre dossier bin
2. Supprimez les fichiers .pdb
3. Reconstruire

Devrait faire l'affaire!

(ce qui est étrange, c'est qu'une reconstruction sans jeter les fichiers .pdb ne fonctionne pas toujours. Je peux voir la date de modification mise à jour, mais toujours quelque part dans la chaîne (débogueur VS2013, IIS, cache d'assemblage), ce changement n'est pas détecté )

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

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

J'ai également rencontré cela. Les conditions qui ont causé mon problème:

• J'exécute une instance IIS7 complète localement
• Je versionne mon logiciel dans des projets séparés

J'avais provoqué cela en ouvrant une version précédente (VS a été invité à me demander si je voulais pointer vers cette instance dans le débogage IIS, j'ai répondu «Oui»), puis en ouvrant la version actuelle (en répondant à nouveau à l'invite IIS avec un «Oui» ), puis tentez de déboguer dans la version précédente.

Pour résoudre, j'ai simplement fermé et rouvert la version précédente et prévue, en l'affirmant une fois de plus comme source de débogage.

Essayez de désactiver et de réinitialiser le point d'arrêt lors de l'exécution en mode débogage au lieu de le faire avant de lancer le mode débogage.

Cela se produit également 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 effectivement trompeur.

La solution consiste à placer la propriété de configuration de prise en charge Common Language Runtime (CLR) dans le projet de démarrage et à recompiler cela.

Si vous avez plusieurs projets dans votre solution , assurez-vous que le projet correct est défini en tant que StartUp Project. Pour définir un projet particulier comme projet de démarrage de votre solution, cliquez avec le bouton droit sur le projet, choisissez Set As StartUp Project.

Après avoir correctement défini mon projet de démarrage, le point d'arrêt souhaité a été atteint par le thread.

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 intégrée, retiré du git repo et reconstruit la solution en vain.

Je tirais une dépendance 64 bits de nuget et dès que j'ai utilisé l'assembly, les sources n'étaient plus intégrées à l'exécutable final et à la place, les sources en cache IDE étaient en cours de construction.

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

C'était une douleur, j'espère que cela apparaîtra dans la liste des réponses pour que tout le monde puisse le voir.

Modifier: il n'y a pas eu d'erreur pendant la génération malgré l'activation de l'option "invite sur erreur de génération" dans les paramètres IDE.

Pour moi, la solution était cachée dans les Advanced Build Settingspropriétés du projet:

Pour une raison inconnue, il était défini sur none: le paramétrer sur fullprovoquait l'atteinte des points d'arrêt.

Pour accéder à cette boîte de dialogue, ouvrez les propriétés du projet, puis accédez à Build, puis sélectionnez le Advanced...bouton en bas de la page.

J'ai eu le même problème dans plusieurs projets dans un projet d'architecture en couches et le problème était dans les configurations, la case à cocher de construction pour le projet sélectionné n'a pas été cochée. le problème a donc été résolu pour un projet.

Pour une autre couche, cela donnait le même problème, même la construction est activée dans les configurations. J'ai fait toutes les autres options comme redémarrer le nettoyage du projet, mais aucune ne m'a aidé. Enfin, j'ai décoché la case de construction pour ce projet particulier et nettoyé et reconstruit. le a de nouveau coché la case et a fait de même. puis le problème a été résolu.

J'espère que cela t'aides..

Dans mon cas, j'étais attaché à un processus en cours d'exécution dans VS 2012. Lors de l'attachement, vous avez la possibilité de déboguer dans différents modes (natif, script, silverlight, managed 2.0, managed 4.0, etc.). Par défaut, le débogueur sélectionne automatiquement le mode. Cependant, Automatic ne fait pas toujours le bon choix. Si votre processus contient plusieurs types de code, assurez-vous que le débogueur utilise le bon.

Dans mon cas, je développais une application Windows CE, testée par rapport à un émulateur. Le problème était que l'exécutable n'était pas déployé sur l'émulateur, donc le .pdb (dans l'environnement de développement) n'était pas synchronisé avec le .exe (dans l'émulateur), car le nouveau .exe n'a jamais été copié sur l'émulateur. J'ai dû supprimer le .exe dans l'émulateur pour forcer un nouveau déploiement. Ensuite, cela a fonctionné.

Ce qui a fonctionné pour moi, c'est de changer la plate-forme de solution de x86 à Any CPU. Après avoir changé pour Any, j'ai défini une adresse d'arrêt, j'ai exécuté le site Web, ouvert la page, cliqué sur le bouton et il s'est arrêté. J'ai fermé le site, suis revenu à x86 et j'ai exécuté la même séquence avec succès.

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. Faites un clic droit sur le raccourci vers VS ou l'exécutable, sélectionnez les propriétés puis la compatibilité .

J'ai d'abord essayé depuis 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 a été résolu pour moi. Il s'agit d'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

Cela m'est arrivé parce que j'avais d'autres projets dans la solution qui n'étaient pas en construction. Après avoir déchargé ces projets problématiques (clic droit sur le projet dans l'explorateur de solutions -> Décharger le projet), j'ai reconstruit la solution et exécuté à nouveau - le point d'arrêt a été atteint!

Il était heureux d'être sur Visual Studio 2017 après avoir ajouté des fichiers existants au projet. Cela a fonctionné pour moi:

1. fermer la solution,
2. aller SolutionFolder\.vs\SolutionName\v15\sqlite3et retirerstorage.ide
3. ouvrez à nouveau la solution

Assurez-vous que vous n'êtes pas en mode Release lorsque vous essayez de déboguer.