Comment remédier au "Le point d'arrêt ne sera pas touché actuellement. Aucun symbole n'a été chargé pour ce document." Attention?
Application de bureau C # sur édition express. Travaillé alors ne fonctionnait pas 5 secondes plus tard.
J'ai essayé le suivant.
- Assurez-vous que la configuration de débogage, l'indicateur de débogage et les informations de débogage complètes sont définis sur tous les assemblys.
- Supprimez tous les dossiers bin et obj et toutes les DLL liées au projet de l’ensemble de mon ordinateur.
- Recréez les projets à l'origine du problème.
- Redémarrez.
J'ai deux projets WinForms dans la solution. L'un d'eux charge les informations de débogage, l'autre non. Ils font tous les deux référence à l'Assemblée sur laquelle j'essaie d'obtenir des informations de débogage exactement de la même manière dans le fichier de projet. Des idées?
Je tiens à ajouter ici, surtout pour moi-même, lorsque je reviendrai pour examiner cette question, que les symboles ne sont chargés que lorsque l'Assemblée est chargée, et que l'Assemblée ne l'est pas avant qu'elle ne soit nécessaire. Si le point d'arrêt se trouve dans une bibliothèque utilisée uniquement dans une fonction de votre assemblée principale, les symboles ne seront pas chargés (et indiqueront que le point d'arrêt n'est pas atteint) jusqu'à ce que cette fonction soit appelée.
Démarrez le débogage. Dès que vous êtes arrivé à un point d'arrêt ou que vous avez utilisé Debug > Break All, utilisez Debug > Windows > Modules. Vous verrez une liste de tous les assemblys chargés dans le processus. Recherchez celui pour lequel vous souhaitez obtenir des informations de débogage. Cliquez dessus avec le bouton droit de la souris et sélectionnez Information de chargement de symbole. Vous obtiendrez une boîte de dialogue contenant la liste de tous les répertoires dans lesquels le fichier .pdb a été recherché. Vérifiez cette liste par rapport à l'emplacement .pdb réel. Assurez-vous qu'il ne trouve pas un ancien.
Dans les projets normaux, l'assembly et son fichier .pdb doivent toujours avoir été copiés par IDE dans le même dossier que votre fichier .exe. Le dossier bin\Debug de votre projet. Assurez-vous d'en retirer un du GAC si vous y avez joué.
Commencez par essayer de reconstruire votre projet en cliquant avec le bouton droit de la souris sur le projet> Reconstruire Si cela ne fonctionne pas, essayez de nettoyer le projet (clic droit sur le projet> nettoyer)
Si cela n'a pas fonctionné, vérifiez ceci:
- Cliquez avec le bouton droit de la souris sur votre projet
- sélectionnez [Propriétés]
- sélectionnez l'onglet [Build]
- assurez-vous que [Définir constante DEBUG] et [Définir constante TRACE] sont cochés
- Cliquez sur le bouton [Avancé] au bas de la page de l'onglet Construction.
- Assurez-vous que [Informations de débogage:] est défini sur [complet]
- Cliquez sur [OK] et reconstruisez le projet ;-)
(l'étape 6 génère les fichiers .pdb, ce sont les symboles de débogage)
Juste quelque chose de simple à essayer - vous l'avez peut-être déjà essayé. Cliquez avec le bouton droit de la souris sur l'explorateur de solutions dans la solution, cliquez sur "nettoyer la solution" pour supprimer tous les fichiers compilés et temporaires associés à une solution .
Effectuez une reconstruction de la solution et essayez à nouveau de déboguer.
J'ai également eu des problèmes avec les points d'arrêt de plusieurs projets dans une solution, certains compilés en tant que x86, d'autres en tant que x64.
Désactivez l'option "Just My Code" dans les paramètres Debug/General.
Croix en affichant ce correctif de Hans K que j'ai trouvé sur le fil de discussion similaire >> ICI << :
Clic droit sur la solution -> Propriétés
Rechercher sous Propriétés communes -> Projet de démarrage
Sélectionnez plusieurs projets de démarrage
sélectionnez Démarrer l’action sur les projets à déboguer.
La réponse choisie m'a amené à résoudre mon problème. Mais je dois faire quelques choses de plus:
Même avec "Debug" sélectionné dans la liste déroulante:
Et dans le projet Propriétés> Construire:
Visual Studio ne chargeait pas de symboles dans un projet spécifique. Donc, dans cette liste déroulante, j'ai sélectionné "Gestionnaire de configuration" et vu que les paramètres de mon projet Web étaient incorrects:
Ensuite, j'ai défini cela sur "Debug" et il a commencé à générer le fichier .pdb. MAISJe dois copier manuellement les fichiers PDB et DLL et les placer dans le dossier que VS recherchait (voici où la réponse sélectionnée m'a aidé):
Debug> Windows> Modules pour voir quels modules étaient chargés, m'a mis dans la bonne direction.
Dans mon cas, IIS Express semblait charger un DLL différent des fichiers ASP.NET temporaires.
La solution?
- Passez à
C:\Users\<YOUR USER>\AppData\Local\Temp\Temporary ASP.NET Files\vs - Supprimer tout dans ce répertoire!
J'ai pu corriger l'erreur en définissant simplement l'option de l'option 'Attacher au processus' sur 'Déterminer automatiquement le type de code à déboguer' comme indiqué dans la capture d'écran ci-jointe.
Suivez simplement les étapes ci-dessous:
- Allez à Debug à partir de la barre de menus
- Cliquez sur Attacher au processus
- Près de l’option Attacher à , cliquez sur le bouton Sélection
- La fenêtre Sélectionnez le type de code apparaîtra
- Sélectionnez maintenant l'option Déterminez automatiquement le type de code à déboguer et cliquez sur le bouton OK.
Vérifiez si votre fichier .pbd est manquant dans votre dossier bin/Debug. Si c'est le cas, allez dans "Propriétés" de votre projet, sélectionnez "Construire" puis "Avancé" en bas Choisissez "complet" sous "Informations de débogage" dans la nouvelle fenêtre qui s’est affichée. C'était mon problème et résolu pour moi.
Parfois, même si cela vous donne cette erreur, la breakpoint reste touchée, alors ignorez simplement l'erreur. Cela se produit assez souvent dans la Views d'un MVC web app.
Dans mon cas, "Optimiser le code" a été coché dans les propriétés de mon projet. Cela a amené VS à voir mon assemblée comme "pas mon code" et à son tour, il n'a pas chargé de symboles pour cela.
La solution consistait à décocher cette . 
Il suffit de vérifier si votre solution est en mode Release.
Essayez d’exécuter Visual Studio en tant qu’administrateur dans Windows.
Dans mon cas, j'essaye de déboguer en mode release. Une fois que je le change en mode débogage. Ça marche
Vous devez activer "Générer les informations de débogage" dans les paramètres du compilateur
Nous avons trouvé la cause de notre problème. Ce code utilisait l'attribut "CodeBehind" dans la directive Page du fichier .aspx au lieu de l'attribut "CodeFile" (ASP.NET 2.0 et versions ultérieures). Après des jours de désespoir, une simple recherche et remplacement a résolu le problème.
L'option "Démarrer le débogage, Debug + Windows + Modules" n'existe pas dans l'édition Microsoft Visual Studio Express 2013.
Décocher "Utiliser le mode de compatibilité gérée" dans Outils Options Le débogage résout ce problème.
J'ai essayé tout ce qui est mentionné ci-dessus, mais rien n'a fonctionné .[Nettoyer la solution et rechercher les fichiers PDB, etc.]
Même la publication de la même solution n'a pas résolu le problème.
Ensuite, je suis retourné à ce que je fais habituellement pour résoudre (tromper ce Visual Studio obstiné).
Tout ce que je faisais était de faire un changement délibéré de code et de publier la solution . Ensuite, j'ai annulé le changement et publié à nouveau.
Voila [PDB débarrasse les esprits du mal] .. Pas une résolution intelligente, mais cela a fonctionné ..: - |
Choses à vérifier juste pour être clair: Assurez-vous que la configuration est définie sur 'Debug' et non sur 'Release'. Vous pouvez déboguer le projet de démarrage en mode "Version", mais pas dans une bibliothèque de classe référencée.
Aucune de ces réponses n'a résolu mon problème. J'ai essayé autre chose en partant du principe que le projet avec l'arrêt n'était pas en réalité le projet chargé. J'ai trouvé que Hans Passant avait écrit que le fichier .dll où je voulais arrêter le débogueur et les fichiers .pdb associés étaient copiés à proximité du fichier .exe. Ces fichiers ont une ancienne date, alors je pensais qu'ils n'étaient pas mis à jour au moment de l'exécution. Je les ai supprimés manuellement, Visual Studio crée une autre paire ET place cette nouvelle paire près du fichier .exe. Maintenant les pauses fonctionnent!
Peut-être que Visual Studio ne peut pas copier et REMPLACER des fichiers existants (.dll et .pdb) à proximité du fichier .exe puisqu'il en existe un autre. Donc, si je supprimais manuellement, VS pourrait en créer un nouveau près de .exe.
Je pense qu'une autre modification (vérifications et ainsi de suite - d'une autre réponse) a déclenché quelque chose et que Visual Studio a copié et remplacé la dll et la pdb du dossier de projet dans le dossier situé près de l'exe, ce qui était une solution.
Je pense que la cause première du problème est que Visual Studio utilise un autre fichier au moment de l'exécution, sans le fichier du projet, avec l'arrêt.
Peut-être que cette réponse pour aider quelqu'un!
Propriétés du projet (puis sélectionnez votre configuration)> Onglet Construction> Avancé ...> Informations de débogage (liste déroulante)
Réglé sur 'all' ou 'pdb-only' puis reconstruit
Au lieu de faire toutes ces choses simplement
Fermer et rouvrir
la solution, il va résoudre le problème
Cela m'a pris un certain temps avant d'essayer les autres options ci-dessus et, pour une raison étrange, le débogage a cessé de fonctionner.
Outil -> Options -> Débogage -> Général -> (décochez) l'option "Exiger que les fichiers source correspondent exactement à la version d'origine"
J'ai eu le même problème et j'ai fait ce qui suit:.
J'intégrais une application C # avec une bibliothèque statique utilisant VS10 - pour laquelle je suis un novice. J'ai écrit un code géré dll pour les interfacer. Je pouvais définir des points d'arrêt partout sauf dans la bibliothèque statique. J'ai reçu le message décrit ci-dessus - aucun symbole n'a été chargé pour ce document. J'ai essayé plusieurs des suggestions ci-dessus. Je pouvais voir que les symboles n'étaient pas chargés. J'ai finalement remarqué une case à cocher Configuration Debug, Activer le débogage de code non géré. Cela m'a permis de définir des points d'arrêt dans les fonctions de la bibliothèque statique.
J'ai également eu le même problème: je reconstruis toute la solution (y compris les projets référencés) en x86 (ou x64)
Même si j'ai défini tous mes projets sur x86 à partir de Configuration Manager (Build-> ConfigManager), certains de mes projets n'étaient pas définis sur x86.
Donc, pour vous assurer que vous faites un clic droit sur le projet et suivez
projet -> propriétés -> onglet Débogage, vérifiez la configuration et la plate-forme.
J'ai lu attentivement toutes les réponses ci-dessus, mais aucune d'elles n'a résolu mon problème.
Dans mon cas, je compilais une bibliothèque de classes (DLL). Aucun module ne semble être chargé dans Debug -> Modules, je ne pouvais même pas charger les symboles manuellement.
Ma solution a été d'ajouter cette ligne à mon code:
System.Diagnostics.Debugger.Launch();
Une fois que ce code est atteint, une exception est déclenchée et .NET Framework affiche une boîte de dialogue vous demandant quelle Visual Studio (nouvelle instance de VS 2008, nouvelle instance de VS 2013, etc.) vous souhaitez utiliser pour déboguer le programme. Vous pouvez choisir l'instance existante de VS avec votre projet chargé. Cela associera le processus à votre session VS et chargera tous les symboles. Vous pourrez maintenant déboguer votre projet.
Bien entendu, la compilation doit être effectuée à l'aide de la configuration Debug, et non de la version.
Je sais que j'ai des années de retard, mais je pensais avoir fait quelque chose de mal et suivi les étapes ci-dessus, puis j'ai réalisé que je mettais la configuration de la solution sur 'Release' par erreur :)
Pour une application ASP.Net, vérifiez les propriétés du site, onglet ASP.NET. Assurez-vous que la version ASP.NET appropriée est sélectionnée.
Si nous obtenons la dernière version de VSTS, tous les fichiers seront en lecture seule. Lors de l'exécution du projet, toutes les classes de la bibliothèque de classes sont en lecture seule et les points de freinage, vides, indiquent "Le point d'arrêt ne sera pas atteint. Aucun symbole chargé pour ce document".
Solution 1
Aller à l'emplacement du projet et lécher le dossier à droite ---> Propriétés ---> onglet Général ---> Décocher en lecture seule (s'applique uniquement aux fichiers du dossier) ---> Appliquer ---> Ok
Solution 2
Démarrez le débogage, sélectionnez Déboguer ---> Windows ---> Modules. Sélectionnez un assemblage et cliquez avec le bouton droit de la souris sur ---> Paramètre du symbole (sélectionné). Définissez le chemin de votre corbeille dans le symbole Cache de ce répertoire et sélectionnez Serveurs Microsoft dans l'emplacement Symbole de PDB. Cliquez sur Charger tous les symboles. Cela prendra du temps. Ensuite, cliquez sur OK.
Maintenant, le statut des symboles de tous les assemblages a été changé de "impossible à trouver ou à ouvrir le PDB" à "Symboles chargés".
Faites un clic droit sur Projet -> Propriétés -> Aller à Construire Onglet -> Désélectionner Optimiser le code . Faites-le pour tout projet de votre solution
cela m'est arrivé après avoir copié un autre fichier webservice asmx dans un service Web existant, ce qui a entraîné la même erreur lors de la tentative de débogage du service ajouté récemment. C'est bizarre, mais c'est la seule façon pour moi de pouvoir déboguer.
Vérifiez que les deux paramètres suivants sont identiques dans Visual Studio:
Faites un clic droit sur le projet de test, allez dans Propriétés, onglet Construire, et regardez Plate-forme cible
Les miens sont tous réglés sur "Tout processeur" donc x64
Dans la barre de menus principale, accédez à Test, Paramètres de test, Architecture de processeur par défaut
Le mien était réglé sur X86
Si vous modifiez ce paramètre en X64 afin de faire correspondre le paramètre ci-dessus, le menu intégré de Visual Studio "Test de (s) débogage (s)" fonctionne et touche les points d'arrêt qui étaient auparavant ignorés avec message “Le point d'arrêt ne sera pas touché actuellement. Aucun symbole n'a été chargé pour ce document ”.
J'ai essayé tout cela et je ne pouvais pas utiliser mon point de rupture ...
Ce que j'ai fait pour résoudre ce problème était
Dans la page où mon point d'arrêt ne touchait pas, j'ai sélectionné le dossier> ajouter un élément existant, puis sélectionné la page à partir de son chemin de sauvegarde. Cela a permis au point de rupture de commencer à fonctionner.
Si vous utilisez un projet C++ ou dll à partir d'un projet C# ou de tout projet .Net, et que vous souhaitez déboguer dans le code natif. Ensuite, accédez au .Net Projet Propriétés -> Débogage -> Activer le débogage de code natif (définissez-le sur true).
Consultez votre liste déroulante Solution Configuration. Assurez-vous de sélectionner Debug et non Release.
Pour moi, le problème était simplement que j'essayais de déboguer dans un projet Web qui n'était pas défini en tant que projet de démarrage . Il n'était donc pas bien compilé lors de l'exécution du débogage et le fichier .pdb n'était pas à jour.
Il suffit de définir le projet sur "Configurer en tant que projet de démarrage".
J'espère que cela t'aides
Lorsque j'essayais de déboguer un complément Excel dans VS 2013, après avoir essayé tous les paramètres de débogage en désactivant DotNet Framework Source Stepping et en désactivant le chargement de symboles, ce qui a finalement fonctionné pour moi a été de changer le paramètre de configuration en version plutôt qu'en mode débogage, puisque le compilateur a semblé enjamber le code et que les points d'arrêt ont finalement été touchés.
Ma situation personnelle était que le débogage fonctionnait dans Visual Studio 2013, où il avait été créé à l'origine, mais ne fonctionnerait pas en 2015. J'ai pu résoudre ce problème en remplaçant la version du fichier de projet par la version 12. version 10.
Je voudrais ajouter une chose supplémentaire qui peut empêcher la progression en interrompant le chargement du fichier .pdb, après ne l’avoir trouvé dans aucun autre forum: si vous ajoutez un post-processus de construction pour ajouter des métadonnées de ressources au DLL (nom de la société, numéro de version, etc.), comme dans "rc.exe my_dll.rc", cela peut être à l'origine d'une mauvaise correspondance entre le fichier DLL et le fichier .pdb. Si les signatures ne correspondent pas, le fichier et tous les symboles nécessaires au débogage ne seront pas chargés. Supprimez cela de la version de débogage.
[WINCE] J'ai rencontré ce problème lors de la compilation sur WinCE, il semblait que l'option "Nettoyer" ne nettoie pas le dossier cible sur le périphérique. J'ai récupéré le débogage/rupture en modifiant le dossier de sortie sur les périphériques. (Propriétés du projet -> onglet Périphériques -> changer le dossier de sortie en un fichier autre que le précédent débogage ayant échoué) - et le tour est joué !! cela fonctionne . Peut-être devrez-vous effectuer un nettoyage manuel de l'appareil, mais ce sera plus tard.
J'espère que cette aide.
Dans mon cas, dans le fichier AssemblyInfo.cs, il y avait la ligne ci-dessous et je l'ai commentée et tout allait bien:
[Assembly: System.Diagnostics.Debuggable(System.Diagnostics.DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]
J'ai parcouru toutes les réponses, rien n'a beaucoup aidé. Dans mon cas, problème avec web.config fichier . C'était <compilation debug="false" strict="true"
J'ai changé pour
<compilation debug="true" strict="false". Maintenant je peux déboguer une application.
Dans mon cas, je déboguais une extension WPF à l'aide de l'instance expérimentale de Visual Studio. Après avoir démarré le débogage, puis mis en pause le duplicateur, j'ai ouvert la fenêtre Debug > Windows > Modules. Là, je pouvais voir le répertoire où Visual Studio essayait de charger les symboles C:\Users\<username>\AppData\Local\Microsoft\VisualStudio\15.0_76a9e536Exp\Extensions\<companyName>. Après avoir arrêté le débogage, j'ai supprimé le dossier cible à l'aide de l'Explorateur Windows et redémarré le débogueur. Visual Studio a ensuite pu atteindre le point d'arrêt.
J'ai fini par relier mon problème à un problème apparemment d'incompatibilité lié à l'utilisation de plusieurs versions de PostSharp . L'application que je tentais de déboguer avait une version précédente de PostSharp, mais faisait référence à un projet utilisant une version plus récente. Pour une raison ou une autre, cela a conduit VS à refuser de générer le fichier PDB pour spécifiquement cette application. (toutes les autres DLL chargeaient bien leurs symboles de débogage).
La solution consistait à mettre à jour PostSharp dans chaque projet vers la version la plus récente et à le recompiler.
Je recevais cela et j'étais perplexe (à l'aide de Visual Studio 2013 Premium).
Normalement, nos applications au travail référencent .dlls dans un répertoire common/app particulier, tel que: C:\OurCompanyApps\xxxxxx.dll. Cela se produisait dans une solution contenant un ensemble de projets WinForm et .dll. Les projets .dll sont compilés dans C:\OurCompanyApps\et les projets WinForm font référence aux fichiers .dll compilés à cet emplacement.
Le problème: J'ai constaté que l'application en question faisait référence au projet .dll dans l'emplacement\Control de la source Source bin au lieu du fichier .dll compilé dans C:\OurCompanyApps.
Solution: J'ai supprimé la référence et l'ajoutée de nouveau à l'emplacement C:\OurCompanyApps \. Ensuite, je pourrais passer en revue les points d'arrêt ajoutés dans le code .dll.
J'espère que ça aide quelqu'un.
Dans mon cas, cela était dû au fait que mon profil de publication (Publier sur un site local IIS) était défini sur Version de configuration, alors que la configuration de la version globale était définie sur Debug. Le profil de publication modifié pour la configuration de débogage a résolu le problème pour moi.
Si vous constatez que vous devez créer des projets dans votre solution individuellement dans un ordre particulier pour obtenir la solution, car la création de la solution directement après un nettoyage ne fonctionne pas et que vous trouvez alors le problème décrit dans la question, cela est peut-être dû à l'inclusion de certains projets supplémentaires faisant référence à des chemins relatifs incorrects, car ils ont été ajoutés à votre solution à partir d'un emplacement différent. Par conséquent, les chemins relatifs ne vont pas au même emplacement que les fichiers .csproj qui se trouvent dans des dossiers directement sous votre fichier .sln.
La raison pour laquelle il serait construit en construisant les projets un par un dans un ordre particulier est que les autres projets font référence aux mêmes bibliothèques, mais ensuite au GAC. La solution finit par créer, mais les symboles qu’elle charge proviennent du GAC et peuvent devenir obsolètes.
La solution consiste à restructurer la structure de dossiers physiques de votre solution et de vos projets, ou à ouvrir les fichiers .csproj individuellement et à fixer les chemins relatifs de sorte que toutes les références à une bibliothèque donnée pointent finalement au même emplacement dans tous les projets. Ou utilisez peut-être le jeton $(SolutionDir).
Et si tout le reste échoue, vous devez obliger Visual Studio à réinitialiser votre configuration de construction. Pour ce faire, vous devez décocher tous les projets de toutes les configurations de construction, puis les revérifier - voir la solution ici .
Assurez-vous que votre code ne soit pas éjecté au moment de la liaison. Même si le compilateur peut reconstruire un objet, si l'éditeur de liens ne voit aucune référence au code, il le jettera et causera cette erreur en tentant de définir un point d'arrêt.
J'ai eu le même problème et j'ai essayé tout ce qui était possible ... certains d'entre eux sont
1) Recherche des fichiers temporaires dans les dossiers temporaires ASP.NET dans les dossiers bin et obj.
2) Décocher le code d'optimisation et activer mon code
3) Naviguer et essayer de charger manuellement les symboles à partir de fenêtres de modules.
4) Vérification de l'indicateur de construction dans les propriétés de la solution ..___.
Et la liste continue ... J'ai passé comme un jour dessus, mais ce qui a finalement fonctionné pour moi, c'est en fait ... Je savais que les symboles de mon projet n'étaient pas chargés et que je ne voyais aucun module dans mon projet. nommer dans la fenêtre des modules soit ...
le problème était que mes symboles étaient importés du chemin de répertoire virtuel du projet ... et que celui-ci était mappé sur le répertoire virtuel d'un autre projet à la place ... le projet Web qui était censé être chargé dans les modules n'y était pas Voici les étapes que j'ai suivies ..
- Faites un clic droit sur le projet Web spécifique et sélectionnez Propriétés
- Aller sur l'onglet Web
- Vous pouvez voir le bouton Créer un répertoire virtuel
- Dès que j'ai cliqué dessus, j'ai vu un message d'alerte disant que "le (nom du projet) est mappé sur (un autre nom de projet)" êtes-vous sûr de vouloir effectuer le remappage? Quelque chose comme ça
- alors il était logique que pour cette raison je voyais le nom de projet inutile dans la fenêtre des modules
- Ensuite, j'ai reconstruit la solution et j'ai réussi à atteindre le point d'arrêt
Dans ma situation, Visual Studio charge les DLL dans Global Assembly Cache (GAC) , et non le DLL dans ma liste de projets. J'ai supprimé les DLL dans GAC et maintenant je peux voir le point d'arrêt fonctionner.
Dans mon cas, cela a commencé après une mise à jour Windows, la mise à jour de Windows a désactivé Internet Information Services, ce qui donnait l'impression que mon API ne parvenait pas à atteindre le point de rupture défini auparavant. était que IIS ne parvenait pas à démarrer et que le code de mon application ne fonctionnait donc pas.
Vérifiez que Internet Information Services est activé dans le menu Fonctionnalités Windows.
Instructions pour IIS:
- panneau de contrôle
- Programmes
- ouvrir ou fermer les fenêtres
- cocher les services d'information Internet
- redémarrer visual studio
Si vous utilisez IIS Express:
Ouvrez 'Ajout/Suppression de programmes' à partir de l'ancien panneau de configuration et effectuez une réparation sur IIS Express. Ou utilisez le Panneau de configuration - >> Programmes - >> Programmes et fonctionnalités - >> Activer ou désactiver les fonctionnalités Windows -> > Internet Information Services et vérifiez le dossier parent Internet Information Services.
J'ai eu cette réponse ici: L'argument spécifié était en dehors de la plage de valeurs valides. Nom du paramètre: site
J'ai eu ce problème.
Mon problème était que les fichiers aspx, aspx.vb et aspx.designer.vb étaient mal importés (ils ont peut-être été importés un par un dans le projet).
Le point d'arrêt se trouvait dans aspx.vb, mais était inaccessible et contenait l'avertissement de cette question.
La solution consistait à supprimer les trois fichiers et à les importer à nouveau. Maintenant je peux atteindre le point d'arrêt.
J'ai nettoyé et reconstruit. Cela ne fonctionnait pas (ça marche habituellement) . Maintenant, je me connecte à w3wp avant d'appeler via le service, puis je le laisse appeler le service une fois, j'ai atteint un autre point d'arrêt, puis je modifie le point d'exécution afin qu'il exécutez la même ligne (appelant le service) à nouveau, puis il s'arrête réellement à mon point d'arrêt dans la méthode de service.
J'utilisais IE8 et j'essayais de modifier certains fichiers JavaScript. Bien que le code était en cours d'exécution, il ne s'arrêtait pas aux points d'arrêt et je recevais le même message sur les points d'arrêt. La mise à niveau vers IE11 a résolu le problème pour moi.
Le projet principal a à la fois une référence de projet et une référence de fichier au même projet.
Dans mon cas, le projet principal avait deux références, une référence de projet et une autre référence de fichier, à la DLL générée par le même projet.
Ainsi, le fichier pdb n'a pas été copié dans le dossier bin du projet principal, ce qui a entraîné l'indisponibilité des symboles.
Avait le problème en essayant de déboguer une application silverlight dans un projet sharepoint. Sous l'onglet sharepoint des propriétés du projet, vous devez activer explicitement le débogage pour les applications silverlight. Sinon, vous obtenez cette erreur.
Il existe de nombreuses réponses avec de nombreuses solutions différentes pour résoudre ce problème.
Une autre solution consiste à vous assurer que votre code est accessible. Par exemple:
Tout code ajouté après un retour dans une fonction . Ajout d'un GOTO qui ignore effectivement votre code qui a le point d'arrêt.
Je ne dis pas que c'est normal, mais ce sont aussi des causes.
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 de VS a reproduit ceci et dit qu'ils y travaillent .
Donc, un correctif consiste à commenter votre ligne charset = utf8 dans le fichier .editorconfig.
Le statut est maintenant "Fixé - en attente de publication" à partir du 9 octobre 2017.
(Merci à John Hatton, "Le point d'arrêt ne sera pas touché pour le moment. Le code source est différent de la version d'origine." Qu'est-ce que cela signifie?
Nous ne vendons pas F11 dans ce pays, nous ne vendons aucun produit ou problème, nous vous proposons un point de vente, un point de retour pour récupération.
Dans mon cas, j'ai donné un F11 dans l'appel de méthode, forçant l'entrée de la méthode où se trouvait le problème BP, le point d'arrêt a donc été récupéré.
Une autre solution pour moi était de post-construire le projet, incapable de pénétrer dans le dossier bin du projet principal.
Lors du débogage d'un assemblage en démarrant une application externe il y a quelques considérations supplémentaires:
L'application externe peut charger ses propres copies d'assemblys (DLL) à partir d'un fichier manifeste. (par exemple, fichier
appname.exe.manifest) Si tel est le cas, vous devez le désactiver, éventuellement en modifiant manuellement le manifeste.L'application externe peut simplement essayer de charger à partir de DLL dans son propre dossier, même sans manifeste. Vous devrez les supprimer/renommer.
Une fois ces étapes effectuées, la version de l’Assembly exécutée dans le débogueur doit être correctement chargée et peut être déboguée normalement.
Après avoir essayé plusieurs de ces techniques, voici ce qui a fonctionné pour moi:
Dans Debug > Options > General, décochez Enable Edit and Continue.
Ma raison était obsolète Telerik OpenAccess ORM. Installé nouvelle version alors cela fonctionne. Doit télécharger et installer. Seule la mise à jour de NuGet n'a pas fonctionné. quelqu'un d'autre l'a aussi mentionné
Également eu ce problème avec un projet généré par Qt .pro. Il s’est avéré que j’ai oublié de définir une variable d’environnement qui détermine les propriétés/général/Répertoire de sortie. Trivial, et un à regarder en premier lieu, mais parfois nous manquons l'évidence.
Il convient également de mentionner que dans certaines situations, le problème se produit, car le projet que vous souhaitez déboguer est un service externe. Dans ce cas, vous devez attacher le débogueur au processus en cours.
Aucune des idées ici ne fonctionnait pour moi, mais je remercie tout le monde pour leurs efforts - dans mon cas, c'était une application Windows qui faisait référence à un projet de bibliothèque de classes - je pouvais déboguer l'application Windows mais pas la bibliothèque de classes. Les fichiers pdb étaient en cours de génération. J'ai cependant trouvé que si je déboguais sur l'appel de la bibliothèque de classe, je pourrais entrer dans la bibliothèque.
Parfois, IIS conservera les fichiers pour une raison quelconque. J'ai dû supprimer le site Web et le créer à nouveau et le problème a disparu
Peut-être n’auriez-vous pas dû faire une AutoPostBack.
Si votre code ne fait pas un PostBack, vous pouvez obtenir cette erreur .
Cordialement.
Projet> Propriétés> C++> Général> Format des informations de débogage - Base de données de programmes (/ Zi)
J'avais vérifié Linker> Debugging et générais déjà des informations de débogage. Lorsque j'ai lancé l'application, des symboles ont été chargés (Debug> Windows> Modules). La définition du format des informations de débogage a résolu le problème pour moi. J'espère que cela aide quelqu'un!
Dans mon cas, aucune de ces solutions n'a fonctionné. Je devais aller à
Outils -> Paramètres d'importation et d'exportation -> Réinitialiser tous les paramètres.
puis le débogage a commencé à fonctionner sans aucun problème.
J'ai eu le même problème, vérifié toutes les solutions précédentes mais ne fonctionnait pas pour moi. Une réponse simple mais supplémentaire, juste pour s'assurer que les gens ne restent pas bloqués sur ce problème qui n'existe pas, comme je l'ai fait.
Ce qui a bien fonctionné pour moi, c’est que j’utilisais VS 2013 en mode administrateur et que j’exécutais en mode normal, ce n’était pas grave. J'ai essayé plusieurs fois de passer en mode normal et en mode administrateur et son fonctionnement constant fonctionne correctement.
IDE: VS 2013 Professional
Version: 12.0.40629.00 Update 5
Je réalise que c'est un vieux fil, mais pour le bénéfice des autres, voici ce qui m'est arrivé. Le problème résidait dans la façon dont j'ai appliqué l'attribut Designer. J'ai créé une classe de designer. Le concepteur a substitué PrefilterProperties pour que les propriétés Anchor, AutoScroll et AutoSize soient en lecture seule.
[System.Security.Permissions.PermissionSet(System.Security.Permissions.SecurityAction.Demand, Name="FullTrust")]
public class j2aScrollableContainerDesigner : ParentControlDesigner
J'ai créé une classe et y ai ajouté mon concepteur. Il s'agit du moyen standard d'attacher un attribut de concepteur à une classe et cela se trouve dans de nombreux exemples MSDN. Le concepteur n'était évidemment pas utilisé car lorsque j'ai placé mon contrôle sur une surface de conception de formulaire, aucune des propriétés mentionnées ci-dessus n'était lue dans la grille de propriétés.
[Designer(typeof(j2aScrollableContainerDesigner), typeof(ParentControlDesigner))]
public partial class j2aScrollableContainer : UserControl
En désespoir de cause, j'ai remplacé la déclaration d'attribut Designer de ma classe par la signature suivante. Le concepteur a été appelé. Je n'ai aucune explication quant à la raison pour laquelle une méthode fonctionne et l'autre pas. Si je reviens à la déclaration d'attribut de Designer ci-dessus, le concepteur cessera de fonctionner.
[Designer(typeof(j2aScrollableContainerDesigner))]
public partial class j2aScrollableContainer : UserControl
Utilisation de Dependency Injection, Autofac dans mon cas, pour résoudre automatiquement en analysant les assemblages. L'un des assemblys référencés n'a pas été résolu.
Mon correctif était de faire directement référence à une classe de l'assembly pour forcer Visual Studio à charger l'assembly. Le simple fait de disposer de l'assembly comme référence ne chargera pas l'assembly lors de l'exécution de l'application.
Vérifiez si vous avez activé "Activer uniquement mon code". Si oui, désactivez-le.
J'avais accidentellement ouvert le fichier de projet dans un éditeur de texte et celui-ci était déchargé. Peu probable, mais vérifiez si vous êtes bloqué.
Cela s'est produit lors du lancement d'un site Web ASP.NET en 2013. Il semble que dans mon cas, il disparaisse une fois le navigateur Web lancé.
Encore une autre solution dans certains cas où cette erreur se produit: vérifiez votre Action de construction .
J'ai eu ce problème dans un projet asp.net MVC3; un de mes contrôleurs avait pour une raison inconnue que Build Action soit défini sur EntityDeploy bien que cela aurait dû être Compile .
Le mien était manquant principalement parce que j'avais deux projets parqués sur la même URL IISExpress, assurez-vous de spécifier un autre port et cliquez sur CreateVirtualDirectory.
J'ai rencontré ce problème en essayant de déboguer l'agent d'arrière-plan d'une application WP7. Il s’est avéré que ce problème de débogage n’était qu’un symptôme du problème réel: mon agent d’arrière-plan ne fonctionnait pas du tout en mode débogage. J'avais suivi le guide suivant sur la mise en œuvre d'un agent d'arrière-plan: http://msdn.Microsoft.com/en-us/library/hh202941(v=vs.92).aspx
... mais j'ai oublié d'ajouter
#define DEBUG_AGENT
ce qui signifie que mon agent n'a jamais été démarré en mode débogage. Une fois que cette ligne a été ajoutée, le problème de ce fil a disparu.
Debug ->Options -> Général -> Décochez la case "Enable Just My Code"
Cela a fonctionné pour moi.
Encore un autre conseil qui a fonctionné pour moi.
Si votre projet/bibliothèque est signé, même tardivement, il ne sera peut-être toujours pas débogué. Essayez de désactiver l’option de signature, de la déboguer, puis de la restaurer.
Les étapes suivantes ont bifurqué pour moi:
- Allez dans le dossier "bin" de votre projet.
- Supprimez le dossier "Debug".
- Construisez votre projet à nouveau.
- Le dossier de débogage sera recréé.
Vous pouvez maintenant recommencer à déboguer.
Pour moi:
- Propriétés de la solution ouverte
- Sélectionnez "Propriétés communes"/"Fichiers sources de débogage"
- Dans la fenêtre "Ne cherchez pas ces fichiers sources", supprimez les fichiers qui s'y trouvent presque certainement à tort.
J'avais défini un point d'arrêt et reçu ce message lors de l'exécution du code. Cependant, le point d'arrêt n'était accessible que pour un test unitaire. Je devais faire un clic droit sur le test unitaire et sélectionner "tests unitaires de débogage" Doh!
Mettons cela ici dans l'espoir que cela aide quelqu'un.
J'ai eu le problème des symboles manquants en ce qui concerne un service Web.
La solution daft était que le projet d'installation n'était pas configuré pour être construit lors de la création de la solution. Cela signifie que lorsque j'ai cliqué avec le bouton droit sur le projet d'installation et que j'ai installé le service, il a été associé au processus. le même service obsolète était en cours d'installation sans la pdb car il ne correspondait pas = pas de points d'arrêt actifs.
La solution manuelle consistait à cliquer avec le bouton droit sur le projet d’installation et à le construire, puis à installer à partir de celui-ci. J'ai ensuite modifié la liste de construction du projet de solution pour inclure le projet d'installation lorsque la solution est générée en mode débogage.
Si vous avez le code C # et le code natif (C/C++), assurez-vous que le débogage natif est activé pour le projet:
1. Cliquez avec le bouton droit sur votre projet de démarrage dans l'Explorateur de solutions.
2. Sélectionnez Propriétés
3. Sélectionnez l'onglet "Debug"
4. Assurez-vous que le débogage de code natif est activé 
Je pense que la source de cette erreur est que les symboles de débogage ont du mal à faire surface pour trouver la solution après avoir créé pour publication.
J'ai essayé toutes les autres réponses - en général, régénérer les symboles .pdb ou vérifier leur emplacement, nettoyer et reconstruire le projet, s'assurer que la configuration active n'est pas la Libération, etc.
Ce qui a finalement fonctionné pour moi est de cliquer avec le bouton droit de la souris sur le projet dans la solution Explorateur> Débogage> Démarrer une nouvelle instance.
Pour mon application Xamarin, le débogage a finalement commencé après que j'ai complètement vidé le dossier Contrôle de code source, que j'ai "Get Latest" et que j'ai reconstruit la solution.
Mon collègue a eu ce problème, a suivi des étapes similaires à celles décrites ici, mais la solution était différente de toutes les solutions données.
Le code qu'elle voulait déboguer se trouvait dans un projet référencé par le projet actuel et il ne s'exécutait jamais dans la session Visual Studio. La DLL s'exécutait à partir du dossier GAC, après avoir supprimé que le projet ne s'exécutait pas du tout, en lançant une exception dès qu'elle tentait de s'exécuter. La solution consistait à inclure le projet référencé dans le dossier local.
De SolutionExplorer:
- Sélectionnez le projet "débogage" que vous allez manquer de
- Développez Références ((si non visible, sélectionnez menu Projet , élément Afficher tous les fichiers )
- Cliquez avec le bouton droit sur le projet dont le point d'arrêt ne fonctionne pas, sélectionnez Propriétés
- Changer la valeur de Copier Local de Faux en Vrai
Réessayer. (Cela a fonctionné pour elle!)
Cela peut être causé par un projet de test, un projet Web ou un autre projet d'exécution ayant une référence Nuget à un projet portant le même nom que le module en cours de chargement.
Prenez les exemples de projets suivants dans une solution:
Vendor.ABCMyLib(références Vendor.ABC)MyProg(programme console: référençant MyLib uniquement)MyProg.Web(projet MVC: référence à MyLib et au projet de solution Vendor.ABC)MyLib.Test(Projet de test: références MyLib et paquet Nuget Vendor.ABC)
MyProg et MyProg.Web chargeront les symboles de débogage .MyLib.Test ne chargera pas les symboles de débogage.