c# - source - Le point d'arrêt ne sera pas actuellement touché. Aucun symbole n'a été chargé pour ce document dans une application Silverlight




le point d'arrêt ne sera pas atteint pour l'instant. aucun symbole n'a été chargé pour ce document (20)

Aller à Propriétés du projet -> Construire -> Avancé ...

Dans la section "Sortie" sélectionnez "complet" dans la liste déroulante Informations de débogage

Ok, ce que j'ai:

Visual Studio 2010 RC, W7 x64, a démarré un nouveau type de projet d'application Silverlight. Hébergement de l'application Silverlight dans un projet d'application Web ASP.NET Silverlight Version 3.0. Ajout d'une classe LinqToSQL, d'un service WCF, d'une application Winform Tester (projet dans la solution) et de quelques classes (également en tant que projets dans la solution).

Hier, soudainement j'ai eu le 'Le point de rupture ne sera pas touché actuellement. Aucun symbole n'a été chargé pour ce document. ' message à apparaître dans l'EDI, mais il n'affecte que le Web Appliaction, je peux déboguer le Silverlight et l'application Winform.

Ce que j'ai essayé / fait pour me débarrasser du message:

  • Réinitialiser les paramètres Visual Studio
  • supprimé tous les fichiers de chaque dossier de fichiers \ Temporary ASP.NET (il y en a un pour chaque 32 bits / 64 bits et pour Framework 2.0 et 4.0)
  • essayé de déboguer en utilisant le serveur Web intégré Visual Studio - normalement j'utilise IIS, dans la sortie du projet de la solution j'ai supprimé tous les dossiers obj et bin dans chaque dossier de projet
  • créé une nouvelle solution et ajouté tous les projets à cette nouvelle solution
  • supprimé le fichier de solution suo
  • créé une nouvelle application Web ASP.NET pour tester s'il s'agit d'un problème d'installation VS => Je peux déboguer ce nouveau projet / solution
  • redémarré la machine plusieurs fois
  • réparé l'installation de vsnet
  • a fait un IISReset
  • supprimé l'application Web d'IIS
  • utilisé le bouton Créer un répertoire virtuel sous Propriétés du projet de l'application Web pour créer une application Web dans IIS
  • a changé la version Framework de chaque projet de 3.5 à 4.0
  • Ouvert la solution sur ma deuxième machine => même comportement
  • a analysé Microsoft Connect pour détecter des bogues / problèmes similaires
  • PASSÉ 7 HEURES.

Donc, cela arrive la deuxième fois de ma vie. la dernière fois que je l'ai résolu en supprimant le dossier de fichiers ASP.NET temporaire, mais cette fois j'ai besoin de votre aide.


Assurez-vous que vous exécutez votre programme en mode DEBUG et non en mode RELEASE.


Cette erreur surgit de temps en temps pour moi et je peux toujours retracer les paramètres du projet pour l'ensemble concerné. Vous n'avez pas à "attendre" jusqu'à ce que votre code ne respecte pas un point de rupture ou jusqu'à ce que vous définissiez le point de rupture, pour savoir quels assemblages ont des symboles chargés.

Lorsque vous exécutez un projet en mode débogage, il affiche dans la fenêtre de sortie les assemblages dont les symboles sont chargés comme indiqué ci-dessous (vous devrez peut-être ouvrir l'image dans un nouvel onglet): T

Donc, dans ce cas, BASD.Core.Data.dll n'a pas de symboles chargés. Vous pouvez alors comparer les paramètres du projet pour cet assemblage à ceux d'un autre assemblage qui a réussi à charger des symboles, afin de déterminer pourquoi certains font et d'autres ne chargent pas de symboles.

"Pour moi" cependant, "chaque fois que cela arrive, c'est parce que l'information de débogage n'est pas créée. Donc j'ouvre Project Properties> Build> Advanced dans un projet (C #).

Donc, pour Basd.Core.Data.dll ci-dessus c.-à-d. Pas de symboles les paramètres de construction avancés étaient:

Alors que pour Basd.Core.Configuration.dll ie un ensemble où je pourrais définir et frapper un point d'arrêt les paramètres étaient:

Donc, je suis sortie des informations de débogage dans le dernier projet et non dans le premier, d'où ma capacité à atteindre le point de rupture dans Basd.Core.Configuration.dll

Notez également qu'il ne suffit pas d'avoir simplement un fichier .pdb dans le dossier bin d'un projet pour un fichier .dll donné car il pourrait bien être obsolète et ne pas être récupéré par Visual Studio en tant que fichier de symbole valide pour le fichier .dll. vous essayez de traverser.

Notez également que la modification des configurations de construction peut modifier les paramètres d'informations de construction et l'origine des symboles.

(Je réalise dans ce cas je suis en mode Release mais la méthode s'applique toujours)


Chaque fois que j'ai eu cette erreur particulière, il s'est avéré que le dossier dans lequel Visual Studio charge des assemblys est différent du dossier à partir duquel l'application Web est exécutée.

Autrement dit, le serveur d'applications exécute l'application à partir de

C:\dev\MyApplication\bin 

mais Visual Studio débogue à partir de

C:\dev\MyOtherApplication\bin (or something along those lines, anyway).

Note - pour diverses raisons, je fais mon débogage avec IIS comme l'hôte de l'application au lieu du gadget autonome que la plupart des gens utilisent. Cela pourrait influencer l'utilité de ma réponse!

Mise à jour :

Pour IIS, le répertoire du serveur d'application (c.-à-d. C:\dev\MyApplication ci-dessus) est le répertoire physique configuré pour l'application Web. Vous pouvez le contrôler en modifiant les paramètres de base de l'application.

Pour Visual Studio, le répertoire de débogage (c.-à-d. C:\dev\MyOtherApplication ci-dessus) est le répertoire dans lequel se svc vos fichiers svc , généralement le même répertoire que votre fichier de projet csproj .


Essayez de définir le projet d'application Silverlight comme un projet de démarrage: cliquez avec le bouton droit de la souris sur le projet -> 'Définir comme projet de démarrage. Ensuite, appuyez sur F5 et voir si vous pouvez attraper des points d'arrêt ...

Essayez de supprimer les données de navigation / temp dans votre navigateur chaque fois que vous modifiez l'application Silverlight


Faites un clic droit sur la solution -> Propriétés

Regardez sous Common Properties -> Startup Project

Sélectionnez plusieurs projets de démarrage

sélectionnez Démarrer l'action sur les projets que vous devez déboguer.


J'ai essayé de renommer le fichier .pdb dans le dossier obj\debug et j'ai fait une solution propre et reconstruire.
Il a créé un nouveau fichier .pdb et j'ai réussi à atteindre les points d'arrêt correctement.


J'ai eu le même problème - j'ai perdu beaucoup de temps à essayer de faire fonctionner le débogage dans Visual Studio.

Il a fini par être Nuget - j'avais 3 versions de Newtonsoft.Json (à travers 7 projets C #). La solution compilait mais n'était pas débogable.

J'ai corrigé le problème en lançant ce qui suit dans la console Gestionnaire de paquets de Nuget:

PM> Mise à jour-Package Newtonsoft.Json


J'ai eu le même problème mais dans VS2013 pour une application Web. Pour moi, la réponse était de mettre à jour la configuration de construction pour la solution: -

  1. Cliquez avec le bouton droit sur la solution et choisissez Propriétés
  2. Sélectionnez la configuration de débogage
  3. Sélectionnez "Configuration" sous "Propriétés de configuration" dans le trivet
  4. Cochez la case "Build" pour chaque projet que vous voulez déboguer

Une fois cela fait, tous mes points d'arrêt ont commencé à fonctionner.


J'ai eu le même problème sous Windows 7 et j'ai tout essayé: les DLL nettoyées, la liste des modules étudiés, j'ai désactivé "Just My Code", et ainsi de suite.

Le problème a été résolu après avoir exécuté Visual Studio en tant qu'administrateur. Honnêtement. Pourquoi Microsoft ne pouvait pas juste me prévenir qu'il ne fonctionne pas "en tant qu'administrateur"? Cela me sauverait quelques heures de travail.


J'ai eu un problème similaire sauf que mon problème était stupide - j'ai eu 2 instances du serveur web intégré fonctionnant sous 2 ports différents ET j'avais mon projet -> propriétés -> web -> "Start URL" pointant vers un port fixe mais l'application Web ne fonctionnait pas réellement sous ce port. Mon navigateur était donc redirigé vers l'URL de démarrage qui faisait référence à 1539 mais l'instance de code / débogage était exécutée sous le port 50803.

J'ai changé le serveur Web intégré pour qu'il fonctionne sous un port fixe et j'ai ajusté mon "URL de démarrage" pour utiliser ce port. projet -> propriétés -> web -> section "Serveurs" -> "Utiliser Visual Studio Development Server" -> port spécifique


J'ai rencontré ce problème lors d'un client où, pour chaque application, ils copiaient la plupart des assemblages partagés dans un dossier " Références ", puis les ajoutaient à la solution en tant que " Solution " et en tant que " Projet ".

Je ne sais pas encore pourquoi, mais certains d'entre eux étaient débogables, d'autres pas, même si dans les paramètres de références pour les assemblages, les chemins complets corrects étaient spécifiés.

Ce comportement imprévisible m'a aussi rendu fou :)

J'ai résolu cela en supprimant tous les assemblys du dossier " References " pour lesquels il y avait des projets avec du code source, et en gardant un très bon suivi des informations de version pour les assemblages partagés.


La raison de ce que vous avez rencontré est que les PDB ("PDB signifie Program Database, un format de fichier propriétaire (développé par Microsoft) pour stocker des informations de débogage sur un programme) ne sont pas à jour, cela peut être dû à certaines raisons :

1- Comme l'a dit Bevan, vous pouvez déboguer une autre application!

2- Vous déboguez une autre version de la même application. Par exemple, vous avez joint une application précédemment construite avec la version actuelle du code pour le débogage sans (re) la construire.

Le nettoyage ou la reconstruction de la solution résout de tels problèmes pour moi.

Pour vous assurer que le problème ne vous appartient pas, essayez de déboguer la même application avec VS 2008 (je crains que ce soit un bogue dans VS 2010 - c'est encore bêta!).


Le problème pour moi s'est avéré être que la case à cocher Properties-> Build-> Optimize code a été activée dans la configuration de débogage. Éteint, reconstruit, et le débogage a fonctionné comme d'habitude.


Les solutions au même problème dans mon cas était la combinaison suivante d'étapes:

  1. Solution -> Propriétés Sélectionnez plusieurs projets de démarrage sélectionnez Démarrer l'action sur les projets que vous devez déboguer.
  2. Suppression du service des références de service et nettoyage de la solution.
  3. Reconstruire le projet de service
  4. Ajouté aux références de service
  5. Nettoyez la solution et reconstruisez-la.

Ouvrez l'URL de l'application Web depuis le navigateur, puis dans l'EDI VS.Net, utilisez Outils -> AttachtoProcess.

puis attacher à aspnet_wp.exe.

Le débogueur commencera à fonctionner


Pour moi le problème était que j'avais "Optimiser le code" activé dans l'onglet Construire des paramètres de mon projet.


Pour mon application WPF, j'ai supprimé le dossier de l'application, j'ai de nouveau "Get Latest" du contrôle de la source, et j'ai reconstruit. Tous les points d'arrêt fonctionnent bien maintenant.


Si vous déboguez un projet Web, assurez-vous que l'attribut debug = "true" a été défini dans votre fichier web.config:

<system.web>
    <compilation debug="true"   .../>

Une autre anecdote qui pourrait être utile

J'ai rencontré ce problème lorsqu'un de mes projets utilisait des références de fichier à partir d'un dossier de sortie de version. Lorsque les résultats de la génération ont été placés dans un dossier de marchandises, ces versions dll écrasaient les DLL de débogage.

La solution était de s'assurer que dans le fichier csproj, HintPath de ma référence était

<HintPath>..\..\Core\Goods\$(Configuration)\MyFramework.dll</HintPath>

et pas

<HintPath>..\..\Core\Goods\Release\MyFramework.dll</HintPath>





iis