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

514

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

.net visual-studio debugging

— David
source

36

recompiler / construire le projet avant d'ajouter le point d'

— arrêt

ouvrez-vous un projet écrit dans une autre version de Visual Studio?

— Mahesh Velaga

2

C'est un projet de site Web. Il ne devrait pas être nécessaire de le construire explicitement. Il devrait compiler lors de l'utilisation. Je soupçonne que VS ne peut pas construire le site Web, mais cela ne me le dit pas! Mahesh - non, tous la même version de VS.

— David

Sur mon cas ..J'ai différentes versions du même code (par exemple test.cs sur la version Live et la version devolopment ..quand j'ai ouvert la version devolopment et mis breakpoint sur test.cs a donné la même erreur mais j'ai compris que je mettais breakpoint test classe .cs qui se rapportait à la version en direct sln pas au développement, vérifiez donc que le cs a déjà une solution de construction)

— dankyy1

5

La suppression des répertoires bin et obj que la reconstruction a fonctionné pour moi.

— Aycan Yaşıt

277

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!

— Veedrac
source

120

Utiliser clean ne fonctionne pas toujours. J'ai dû supprimer manuellement tout dans mon dossier bin pour le faire fonctionner à nouveau.

— Carra

3

J'ai eu par erreur une référence à une DLL dans mon dossier bin. Correction du chemin de référence corrigé.

— Brad Urani

39

Pour moi, même la suppression des dossiers bin et obj n'a pas fonctionné. J'ai également dû redémarrer Visual Studio.

— d512

1

J'ai passé presque une journée à trouver la solution. Merci beaucoup d'avoir fourni une solution.

— Racs

8

J'ai fermé VS, supprimé tous les dossiers bin et obj, tout reconstruit, vérifié les configurations de construction, la construction réussit. Pas de dé. Les choses simples ne devraient pas être aussi compliquées. >: |

— snarf

129

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.

— Oliver
source

Merci pour la suggestion Oliver. Ce n'est certainement pas arrivé ici, je remarquerais assez rapidement si l'un de mes projets n'était pas en train de se construire.

— David

3

J'avais exactement le même problème, mais je n'avais rien de non contrôlé. il était juste construit pour x86 dans cette boîte de dialogue, alors que ma machine locale est x64! J'ai donc sélectionné l' Any CPUoption et cela fonctionne à nouveau.

— JP Hellemons

3

Supprimer des projets de la configuration de débogage sans raison valable devrait être un péché cardinal, car cette configuration peut très bien être utilisée par la machine de construction de CI (je sais qu'elle est ici), donc pourrait finalement passer quand elle devrait échouer. Je sais que cela pourrait être l'une des nombreuses étapes de construction, mais quand même ... @Oliver J'espère que le membre de l'équipe vous a acheté des biscuits! :)

— Fetchez la vache

J'ai eu ce problème lorsque j'ai changé pour construire pour x86 au lieu d'AnyCPU. Il a supprimé des projets de construction pour une raison inconnue.

— Adam Pedley

Le projet est répertorié pour Build dans le gestionnaire de configuration, cela ne m'a donc pas aidé, je le crains :(

— Ortund

43

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.

— AnthonyVO
source

2

Vider les fichiers temporaires dans le répertoire windows a fonctionné pour moi, cheers!

— ChrisFletcher

7

Je voulais juste ajouter une réponse similaire - assurez-vous qu'aucune ancienne copie de la DLL de votre projet ne traîne dans aucun des dossiers temporaires qu'ASP.NET utilise, comme C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Fichiers ASP.NET temporaires - comme mentionné - mais aussi C: \ Windows \ Microsoft.NET \ Framework_64_ \ v4.0.30319 \ Fichiers ASP.NET temporaires . J'utilise Tout pour rechercher rapidement ces copies .

— Oliver

12

Juste un petit conseil: taper %localappdata%dans la zone de recherche vous amène directement àC:\Documents and Settings\%username%\AppData\Local

— dav_i

1

Peut confirmer que cela a fonctionné pour moi dans Visual Studio 2013 sur un projet de service Web.

— Moeri

J'ai fait tout cela mais cela ne semble pas avoir aidé. J'étais vraiment excité de voir ça aussi.

— Ortund

40

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

— Codeleuth
source

Je ne pense pas l' avoir fait. Merci pour le lien cependant. Cela m'a donné un aperçu de ce que signifie cette invite!

— David

11

Visual Studio avait cette option depuis des décennies maintenant (au moins VS98 l'avait). Je n'ai jamais compris pourquoi quelqu'un voudrait exécuter la dernière version réussie. Après tout, si c'était ce que je voulais, je l'aurais lancé directement, car je ne pouvais pas déboguer de toute façon. Ne pas lancer aurait été un défaut plus judicieux.

— OregonGhost

6

Je l'ai utilisé plusieurs fois pour exécuter le projet (pour une raison quelconque, comme pour montrer à quelqu'un d'autre) alors que je suis encore en train d'écrire du code qui ne compilera pas. Parfois, c'est pratique. Personnellement, je le laisse désactivé.

— Codesleuth

3

Peut-être s'ils devaient montrer leur supérieur quand il est soudainement passé. Ils pourraient toucher f5 et être comme "vous voyez, ça fonctionne!"

— Gigala

33

Aller à

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

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

— Rachmad
source

17

@Rachmad Cette solution fonctionne. Mais cela ne semble pas être la solution complète, car cela signifie que nos fichiers source ne correspondent pas exactement à la version d'origine

— onmyway133

C'est exactement ce que je cherchais par @entropy est juste. Bien que cela permette de définir les points d'arrêt, le fait est que la source utilisée ne correspond pas à la pdb utilisée. La meilleure solution est de résoudre ce problème. En des temps impossibles, cela fonctionne très bien.

— JamesG

Même avec cela non contrôlé, l'exécution n'atteint pas le point d'arrêt et l'erreur persiste

— Ortund

12

Ce n'est PAS une solution à ce problème mais une solution de contournement. Évidemment, je ne veux pas travailler avec des fichiers obsolètes dans le débogueur.

— Obi Wan

2

@ObiWan Pas évident. J'aime faire des modifications mineures et continuer le débogage même en sachant que la source et la construction sont différentes.

— Alan Baljeu

30

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

capture d'écran du menu

— AdiKonstantin
source

1

C'était mon problème. J'avais compilé en mode débogage, changé le code, puis exécuté plus tard en mode release. Pas étonnant que le débogueur ait pensé que le code était différent - les symboles de débogage étaient différents. Lorsque j'ai supprimé le dossier bin comme d'autres l'ont suggéré, j'ai reçu une erreur «aucun symbole n'a été chargé pour ce document». Ce n'est qu'à ce moment-là que j'ai établi la connexion et que je me suis dirigée vers cette réponse. Il faut plus de votes!

— indot_brad

Il est possible que le projet soit désactivé pour la génération, même dans la configuration de génération de débogage. Un examen de la configuration de build est nécessaire, le basculement entre les configurations de débogage / libération est inutile.

— Asad Saeeduddin

C'était aussi pour moi. essayé de nettoyer, reconstruire les autres solutions référencées en vain. Je n'ai pas remarqué que la solution me regardait en face

— Adam Hey

C'est ce qui m'est arrivé - je construisais mon projet et remplaçais mes DLL à plusieurs reprises mais le problème ne disparaîtra pas. J'ai réalisé que le code était construit en mode Release pendant que je remplaçais les dll du dossier / bin / debug. Stupide que je suis.

— displayName

Je voulais m'attacher à un processus qui était construit en mode release. Passer au débogage a résolu mon problème.

— fivef

27

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.

— Tormod
source

1

Il convient également de garder à l'esprit, mais je ne pense pas que ce soit le problème ici, car j'essaie de pénétrer dans un projet de site Web, pas dans une bibliothèque de classes.

— David

24

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.

— Luke Whyte
source

4

La fermeture de Visual Studio a également fonctionné pour moi. Aussi, avec des actions Clean / Rebuild.

— danielB

3

Cela a corrigé la solution dans VS 2015

— TaintedLemon

3

Fixed isue in VS 2017

— Daniel Fisher lennybacon

Correction du problème dans VS 2012

— seebiscuit

19

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.

— John Hatton
source

Le statut est désormais "Fixe - version en attente" depuis deux jours (9 octobre 2017). Ce qui est une bonne nouvelle, car l'UTF-8 est le seul défaut sain pour l'encodage de texte de nos jours. :-)

— rmunn

Je remarque également que la cause ultime de ce problème était apparemment cet autre correctif , où il charset=utf8était interprété comme "UTF-8 avec BOM". Changer cette interprétation en "sans nomenclature" a cassé certains fichiers UTF-8 qui contenaient la nomenclature. Donc, si vous rencontrez ce problème et que le correctif Visual Studio n'a pas encore été publié, essayez de supprimer la nomenclature au début de vos fichiers texte et cela peut résoudre le problème. (Ce commentaire est mendie pour une référence Wing Zéro ... :-))

— rmunn

C'était aussi le problème pour moi. Actuellement, cela n'est pas corrigé ou au moins encore publié ou un bug a été réintroduit (version 15.4.2)

— avidenic

12

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.

— Stijn
source

Je vois ce que vous voulez dire, et cela mérite d'être gardé à l'esprit pour l'avenir, mais la source en question ici est un projet de site Web, pas une bibliothèque de classe.

— David

C'est un problème commun lorsque je récupère du code hérité qui me laisse me gratter la tête en me demandant quel génie a décidé de référencer une DLL à partir d'un projet dans la solution qui n'est utilisé que par un autre projet dans la solution. soupir

— Kell

10

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

— Mehrdad Babaki
source

7

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.

— Tomi
source

Je ne peux pas attribuer +1 suffisamment J'ai récemment réinstallé Windows et je n'ai pas remarqué que mon horloge système était éteinte. Effectivement, ce changement a tout foutu, et la reconstruction de la solution / du projet entier l'a corrigé comme par magie.

— Kyle Baran

7

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

— JBSnorro
source

J'ai fait face exactement au même problème. Votre réponse m'a aidé! Je vous remercie! +1

— jweyrich

5

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

Accédez à votre dossier bin
Supprimez les fichiers .pdb
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é )

— FrankyHollywood
source

Build-> Clean Solution devrait également accomplir la suppression des fichiers qui doivent être supprimés.

— Dave

Après une énorme perte de temps en raison de ce problème, cette solution a fait l'affaire. Thx FrankyHollywood

— AD

4

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.

— Stijn
source

4

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.

— baker.nole
source

3

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.

— mikeTheLiar
source

3

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.

— Stijn
source

3

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.

— Afficher un nom
source

Il convient également de noter que si votre point d'arrêt se trouve dans un projet qui n'est PAS votre projet de démarrage et qu'il NE PEUT PAS être fait de votre projet de démarrage (car, par exemple, vous devez avoir un projet différent comme projet de démarrage), vous pouvez (après avoir démarré le principal) clic droit et choisissez Debug >> Start New Instance of the project that has the breakpoint in that you want to hit

— Caius Jard

3

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.

— nurettin
source

3

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.

— riqitang
source

3

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

— Priyankara
source

2

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.

— ton silencieux
source

Dans mon cas, je me connectais à w3wp.exe pour déboguer du code .NET, mais pour une raison quelconque, il attachait le débogueur de script qui ne pouvait pas voir mes points d'arrêt C #. Le changer en débogueur .NET a permis à mes points d'arrêt C # de fonctionner.

— Oran Dennison du

2

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

— Julen
source

2

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.

— John
source

2

Peut-être que le choix du CPU n'affecte pas du tout le problème et que c'est juste le fait qu'il force une reconstruction?

— jwg

Il utilisera un autre dossier bin, il y avait probablement une ancienne dll dans votre carte CPU.

— Carra

J'ai eu ce problème lors de la plate-forme active x86 (que je n'ai jamais utilisée), le retour à Win32 a résolu le problème. Le PC est partagé, donc quelqu'un d'autre a configuré cette plate-forme pour une raison quelconque.

— Zac

2

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

— Pete
source

1

Ce qui pourrait se produire ici, c'est que la configuration de votre version passe de x32 à x64 lorsque vous désactivez le mode de compatibilité et que tous vos projets ne sont peut-être pas sélectionnés pour être intégrés à x32. La raison pour laquelle certains projets sont désactivés pour la construction dans x32 est quelque chose dont vous devrez parler aux membres de votre équipe.

— Asad Saeeduddin

C'était exactement mon problème. Je vous remercie!

— Johan Holtby

2

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

— Teoman shipahi
source

2

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!

— Sarah
source

2

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

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

— laurien
source

Merci pour cette solution! Aucun auparavant, et cela m'a sauvé la journée :)

— StefanaB

2

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

— Entrez
source