Le point d'arrêt ne sera pas touché actuellement. Aucun symbole n'a été chargé pour ce document dans une application Silverlight
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, tout à coup, j'ai reçu le message 'Le point d'arrêt ne sera pas touché pour le moment. Aucun symbole n'a été chargé pour ce document. ' message à apparaître dans l'EDI, mais cela n'affecte que Web Appliaction, je peux déboguer Silverlight et Winform App.
Ce que j'ai essayé/fait pour me débarrasser du message:
- Réinitialiser les paramètres de Visual Studio
- a supprimé tous les fichiers de chaque\Dossier de fichiers temporaire 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 à l'aide du serveur Web Visual Studio Integrated - normalement, j'utilise IIS, dans la sortie de projet de la solution, j'ai supprimé tous les dossiers obj et bin de chaque dossier de projet
- créé une nouvelle solution et ajouté tous les projets à cette nouvelle solution
- supprimé le fichier solution suo
- créé une nouvelle application Web ASP.NET pour vérifier s’il s’agit d’un problème d’installation VS => Je peux déboguer ce nouveau projet/cette nouvelle solution
- redémarré la machine plusieurs fois
- réparé l'installation vs.net
- a fait un IISReset
- supprimé l'application Web de IIS
- utilisé le bouton Créer un répertoire virtuel sous Propriétés du projet de l'application Web pour créer une nouvelle application Web dans IIS
- changé la version du framework de chaque projet de 3.5 à 4.0
- A ouvert la solution sur ma deuxième machine => même comportement
- exploré Microsoft Connect pour les bugs/problèmes similaires
- A dépensé 7 heures.
Donc, cela se produit la deuxième fois de ma vie. la dernière fois que j'ai résolu le problème en supprimant le dossier Temporary ASP.NET Files, mais cette fois j'ai besoin de votre aide.
Clic droit sur la solution -> Propriétés
Regardez 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.
J'ai eu le même problème et après avoir cherché sur Google, j'ai trouvé deux solutions typiques:
Assurez-vous que le débogueur Silverlight est activé dans le projet .Web. Ouvrez les propriétés du projet et sélectionnez le débogueur Silverlight sous l'onglet "Web".
Redémarrez Visual Studio et supprimez tous les dossiers bin et obj.
Mais aucun de ceux-ci n'a fonctionné pour moi . Ensuite, quelqu'un a mentionné un fil de discussion très bas pour essayer d'utiliser plutôt IE comme navigateur. Cela a permis au débogage et aux points d'arrêt de fonctionner à nouveau!
Modifier:
Plus tard, j’ai eu du mal avec IE9 qui ne fonctionnait pas, parce qu’il s’attachait au mauvais processus. Au lieu d’attacher manuellement le processus IE correct à chaque fois, j’ai trouvé un joli astuce :
- Cliquez avec le bouton droit sur l'une des pages générées dans le projet .Web (.html ou .aspx).
- Cliquez sur "Parcourir avec ..."
- Définissez IE comme navigateur par défaut (n'affectera que le choix du navigateur par Visual Studio)
Désormais, Visual Studio lancera IE lors de l'exécution du projet .Web et se joindra au processus approprié. Ça devrait le faire.
Chaque fois que j'ai eu cette erreur particulière, il s'est avéré que le dossier à partir duquel Visual Studio charge les assemblys est différent du dossier à partir duquel l'application Web s'exécute.
C'est-à-dire que le serveur d'applications exécute l'application à partir de
C:\dev\MyApplication\bin
mais Visual Studio est en train de déboguer
C:\dev\MyOtherApplication\bin (or something along those lines, anyway).
Remarque - pour diverses raisons, je fais le débogage avec IIS en tant qu'hôte d'application au lieu du gizmo autonome dinky 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'applications (c'est-à-dire C:\dev\MyApplication ci-dessus) est le répertoire physique configuré pour l'application Web - this peut être contrôlé en modifiant les paramètres de base de l'application.
Pour Visual studio, le répertoire de débogage (c'est-à-dire C:\dev\MyOtherApplication ci-dessus) est le répertoire dans lequel se trouvent vos fichiers svc, généralement le même répertoire que votre fichier de projet csproj.
Le problème pour moi s'est avéré que la case Propriétés-> Construire-> Optimiser le code avait été activée dans la configuration du débogage. Désactivé, reconstruit, et le débogage a fonctionné comme d'habitude.
La raison de votre situation est que les PDB ("PDB" signifie "base de données de programme, un format de fichier propriétaire (développé par Microsoft) pour stocker les informations de débogage concernant un programme") ne sont pas à jour, cela peut être dû à certaines raisons. :
1- Comme Bevan l'a dit, vous êtes peut-être en train de déboguer une autre application!
2- Vous déboguez une autre version de la même application. Par exemple, vous avez associé une application précédemment construite à la version actuelle du code pour le débogage sans la (re) construire.
Nettoyer ou reconstruire 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 ne soit un bug dans VS 2010 - il est toujours en version bêta!).
J'ai eu le même problème, je déboguais mon projet et je devais faire un clic droit sur le projet et sélectionner "nouvelle instance de débogage". Je n'avais besoin que de faire cela une fois, puis après cela a fonctionné normalement.
Cette erreur survient de temps en temps pour moi et je peux toujours la retrouver dans les paramètres du projet pour l’Assemblée concernée. Vous n'avez pas à "attendre" jusqu'à ce que votre code ne respecte pas un point d'arrêt ou jusqu'à ce que vous le définissiez pour savoir quels assemblys ont des symboles chargés.
Lorsque vous exécutez un projet en mode débogage, il indique dans la fenêtre de sortie les assemblages contenant des symboles chargés comme ci-dessous (vous devrez peut-être ouvrir l'image dans un nouvel onglet): T
Donc, dans ce cas, les symboles ne sont PAS chargés dans BASD.Core.Data.dll. Vous pouvez alors comparer les paramètres de projet de cet assemblage à ceux d'un autre assemblage qui a réussi à charger des symboles, afin de déterminer pourquoi certains le font et d'autres pas.
"Pour moi" cependant, "chaque" fois que cela se produit, c'est que les informations de débogage ne sont pas créées. J'ai donc ouvert Propriétés du projet> Construire> Avancé dans un projet (C #).
Donc, pour Basd.Core.Data.dll ci-dessus, c’est-à-dire qu’aucun symbole, les paramètres de construction avancés étaient:
Alors que, pour Basd.Core.Configuration.dll, c’est-à-dire un assemblage où je pouvais définir et atteindre un point d’arrêt, les paramètres étaient les suivants:
Donc, je produis des informations de débogage dans ce 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 se peut qu’il soit obsolète et qu’il ne soit donc pas récupéré par Visual Studio comme fichier de symbole valide pour le fichier .dll. vous essayez de passer à travers.
Notez également que le fait de modifier les configurations de construction peut modifier les paramètres d’information de construction et d’où les symboles sont extraits.
(Je réalise que dans ce cas je suis en mode Release mais la méthode est toujours valable)
Aller à Propriétés du projet -> Construire -> Avancé ...
Dans la section "Sortie", sélectionnez "Complet" dans la liste déroulante Informations de débogage.
Assurez-vous que vous exécutez votre programme en mode DEBUG et non en mode RELEASE.
Je viens de résoudre ce problème selon Déploiement d'applications Silverlight . (Cette réponse est une copie de certaines autres, mais je vais essayer de l'expliquer plus en détail.)
Le problème est probablement que votre application Silverlight n'est pas déployée correctement sur votre application Web lors de la génération/du démarrage. C’est un problème de référencement - c’est simple à comprendre, mais pas évident la première fois que vous le rencontrez.
Comme toute autre référence de projet, la sortie du projet référencée doit être copiée dans le référencement le dossier bin du projet afin de déboguer. Pour les bibliothèques de classes, cela se produit lorsque vous cliquez avec le bouton droit de la souris et sélectionnez "Ajouter une référence ...". Pour Silverlight, vous devez ajouter une référence via les propriétés du projet.
- Faites un clic droit sur votre projet et sélectionnez "Propriétés".
- Sélectionnez l'onglet "Silverlight Applications" à gauche
- Appuyez sur le bouton "Ajouter ..." et sélectionnez votre projet Silverlight dans la boîte de dialogue.
Cela ajoute une référence à l'application Silverlight à partir de votre application Web d'hébergement et garantit que le fichier xap sera copié dans l'application Web lors de la génération ou du déploiement. Cela signifie que l'application Silverlight actuelle et ses fichiers de débogage sont à l'intérieur de l'application en cours de débogage, et vous pourrez parcourir le code.
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" .../>
J'ai eu le même problème sur Windows 7 et essayé tout: DLL nettoyées, liste des modules examinés, désactivation de "Just My Code", etc.
Le problème a été résolu après avoir exécuté Visual Studio "en tant qu'administrateur". Honnêtement. Pourquoi Microsoft ne pouvait-il pas simplement m'avertir que c'est pas exécuter "en tant qu'administrateur"? Cela me ferait gagner quelques heures de travail.
Pour moi, le problème était que l'option "Optimiser le code" était activée dans l'onglet Construction des paramètres de mon projet.
Debug -> Attacher au processus ->
choisir Déboguer ces types de code: option ->
select géré v3.5, v3.0, v2.0 ou géré v4.5 , v4.0 
Eu le même problème
Pour une raison quelconque, l'une des DLL a été enregistrée dans le GAC. Par conséquent, sa version était toujours différente de celle du code.
Une fois que je l'ai retiré du GAC, le problème a été résolu.
Pour ceux qui lisent et qui utilisent Visual Studio 2008, pas Visual Studio 2010, obtiennent cette erreur. Les réponses ci-dessus ne m'ont pas aidé dans cette situation, je partage donc mon expérience.
Si vous déboguez une application Web IIS dans Visual Studio 2008 en vous connectant au processus w3wp.exe plutôt que d'utiliser le serveur de développement ASP.NET pour le débogage (commencez par le débogage), voici peut-être votre problème:
Il est possible que Visual Studio fasse toujours référence à un fichier de symboles (fichier utilisé lors du débogage) à partir de votre dll à partir d'un processus IIS obsolète. Et ce fichier de symboles a été recréé par une recompilation du code source .NET, mais le processus IIS fait toujours référence à l'ancien fichier de symboles.
Pour résoudre:
Arrêtez simplement le débogage dans Visual Studio, redémarrez l'application Web et reconnectez-vous au processus. Ensuite, les points d'arrêt doivent passer du jaune (lorsque vous voyez cette erreur) au rouge.
=========================
Plus de choses à essayer (trouvé une nouvelle situation aujourd'hui):
Faites chaque puce dans le lien ci-dessous ONE AT A TIME, mais répétez mes étapes ci-dessous pour chacune de vos tentatives.
1.) Arrêtez le débogage (appuyez sur l'icône du carré rouge) dans Visual Studio
2.) Solution propre
3.) Solution de construction
4.) [INSÉRER L'INSTRUCTION DE BALLE ICI]
5.) Outils> Attacher au processus (ou commencer par le débogage)
6.) Démarrez le programme auquel vous vous attachez et exécutez-le de manière à ce que votre code soit touché.
6 a expliqué:
Si vous vous connectez à nunit.exe, ouvrez NUnit et exécutez un test pour que votre point d'arrêt soit touché.
Si vous vous connectez à w3wp.exe (site IIS), ouvrez votre site dans le navigateur et accédez à la page qui touchera votre point d'arrêt.
MODIFIER:
Aujourd'hui, j'ai remarqué que si vous essayez de déboguer un projet qui n'est pas défini en tant que projet de démarrage, cela s'affichera. Lorsque vous vous attachez à votre processus w3wp.exe, il réfléchit à son débogage sur le projet défini en tant que projet de démarrage. Pour résoudre le problème, il suffit de cliquer avec le bouton droit de la souris sur le projet d’application Web et de choisir "Définir comme projet de démarrage". Ensuite, essayez de vous rattacher à votre processus.
Le scénario est le suivant: un projet particulier est votre projet de démarrage (par exemple, a la méthode Main). Ce projet référence d'autres projets dans votre solution. Les points d'arrêt dans les autres projets ne sont pas touchés.
Solution rapide: lorsque vous générez votre solution, recherchez le projet de démarrage dans le chemin de sortie de la compilation (généralement bin\Debug). Examinez les fichiers DLL et PDB pour les projets que vous référencez. Assurez-vous que la date de leur dernière modification correspond à la date de la dernière création de votre solution. Si ce n'est pas le cas, copiez-les à partir du chemin de sortie de la construction pour chaque projet dans votre chemin de sortie de la génération des projets de démarrage. Par exemple:
Projet A a Main. Il fait référence au projet B. Vos points d'arrêt ne sont pas touchés dans le projet B. Copiez les fichiers DLL et PDB du chemin de sortie de la construction du projet B vers le chemin de sortie de la construction du projet A. Puis lancez votre solution. Le point de rupture va maintenant être touché.
Vous devez maintenant comprendre pourquoi le projet A ne copie pas le fichier DLL et le fichier PDB du projet B. Les réponses ici couvrent la plupart des scénarios. Un scénario qui n’a pas été abordé consiste à s’assurer que vos projets et votre solution sont correctement liés à TFS. J'avais des projets liés et d'autres pas correctement. Cela a causé le problème pour moi. Une fois que j'ai résolu ce problème, le problème a disparu et je n'ai plus eu à copier sur les fichiers DLL et PDB.
La solution au même problème dans mon cas était la combinaison suivante d'étapes:
- Solution -> Propriétés Sélectionnez plusieurs projets de démarrage et sélectionnez l’action Démarrer sur les projets à déboguer.
- Suppression du service des références de service et nettoyage de la solution.
- Reconstruire le projet de service
- Ajoutée aux références de service
- Nettoyez la solution et reconstruisez-la.
Pour résoudre ce problème dans Web.config, il me suffisait d'ajouter debug="true"
<system.web>
<compilation targetFramework="4.0" debug="true">
Ce qui m'a aidé à trouver cette solution a été de regarder Modules windows lors du débogage et de constater que pour mes DLL ASP.NET chargées, j'avais: Le binaire n'a pas été généré avec informations de débogage
J'ai eu le même problème, mais dans VS2013 pour une application Web. Pour moi, la réponse a été de mettre à jour la configuration de construction pour la solution: -
- Cliquez avec le bouton droit sur la solution et choisissez Propriétés.
- Sélectionnez la configuration de débogage
- Sélectionnez "Configuration" sous "Propriétés de configuration" dans le sous-jeu.
- Cochez la case "Construire" pour chaque projet que vous souhaitez déboguer
Une fois que j'ai fait cela, tous mes points d'arrêt ont commencé à fonctionner.
J'ai essayé de renommer le fichier .pdb dans le dossier obj\debug, puis de nettoyer et de reconstruire une solution.
Il a créé un nouveau fichier .pdb et j'ai pu atteindre les points d'arrêt correctement.
Ouvrez l'URL de l'application Web à partir du navigateur, puis dans le VS.Net IDE utilisez Outils -> AttachtoProcess
attachez ensuite à aspnet_wp.exe.
Le débogueur commencera à fonctionner
D'accord, c'est parti:
(Dans une "application silverlight": veuillez d'abord vérifier que silverlight est coché "web" dans votre projet de serveur "propriétés" - Si cela ne l'a pas résolu, essayez ceci ci-dessous)
La première fois, faites ceci: exécutez ceci en premier: devenv.exe/ResetSettings et 1: dans le menu supérieur, cliquez sur la balise de débogage 2: cliquez sur les options et les paramètres 3: dans "débogage" et sous "général", recherchez "activer le code source .net" 4: Cochez la case. 5: Et maintenant tous les symboles seront téléchargés et reconfigurés :)
Si cela se reproduit après ce qui précède, effacez simplement le dossier contenant les symboles:
1: Dans le menu du haut, cliquez sur la balise de débogage 2: cliquez sur les options et les paramètres. 3: Dans "débogage" et sous "symboles", recherchez le bouton "cache de symboles vide" et cliquez dessus.
Pour mon application WPF, j'ai supprimé le dossier de l'application, "Get Latest" à nouveau dans le contrôle de code source, puis reconstruit. Tous les points d'arrêt fonctionnent très bien maintenant.
J'ai eu le même problème - perdre beaucoup de temps à essayer de faire fonctionner le débogage dans Visual Studio.
Il s’est finalement avéré être Nuget - j’avais 3 versions de Newtonsoft.Json (sur 7 projets C #). La solution compilerait mais n'était pas débogable.
J'ai résolu le problème en exécutant ce qui suit dans la console du gestionnaire de packages de Nuget:
PM> Package de mise à jour Newtonsoft.Json
Je devais désinstaller manuellement toutes les instances du fichier .dll du registre et toutes les instances du fichier .dll de mon lecteur local. Désinstallé/réinstallé mon application et maintenant im frapper des points d'arrêt! J'ai perdu une demi-journée en faisant ceci :(.
Une autre anecdote qui pourrait être utile-
J'ai rencontré ce problème lorsque l'un de mes projets utilisait des références de fichier à partir d'un dossier de sortie Release. Lorsque les résultats de la construction ont été placés dans un dossier Goods, ces DLL de version remplaçaient les DLL Debug.
La solution a été 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>
Supprimez le fichier .xap si votre point d'arrêt n'est pas touché. Dans YourProject.Web/ClientBin Supprimez YourProject.xap. J'ai essayé tout ce qui précède et tombé sur ce correctif, fonctionne à chaque fois. Sage de nettoyer le projet après avoir supprimé aussi.
Essayez de définir Silverlight Application Project en tant que projet de démarrage: cliquez avec le bouton droit de la souris sur projet -> 'Définir comme projet de démarrage. Puis appuyez sur F5 et voyez si vous pouvez attraper des points d'arrêt ...
Essayez de supprimer les données de navigation/temporaires de votre navigateur à chaque fois que vous apportez des modifications à l'application silverlight.
J'ai eu le même problème. Suivre a travaillé pour moi
Allez au web application --> Properties --> Silverlight Applications
Si vous ne voyez pas votre application Silverlight dans la liste, cliquez sur Ajouter et sélectionnez votre application Silverlight dans le menu déroulant "Projet", puis ajoutez-la.
J'utilise VS 2008 et j'ai eu cette erreur. J'ai essayé tout le reste suggéré ici et sur d'autres sites Web mais rien n'a fonctionné.
La solution était assez simple et il y avait deux autres solutions mentionnées sur cette page qui me mettaient dans la bonne zone.
Allez dans le menu Projet et cliquez sur Propriétés (vous pouvez également cliquer avec le bouton droit de la souris sur le nom du projet dans l'explorateur de solutions et sélectionner Propriétés).
Sélectionnez l'onglet Compile à gauche.
Dans la zone de texte "Build output path:", assurez-vous que vous avez "bin \" dans la zone de texte.
Dans mon cas, cela pointait vers un autre dossier bin sur le réseau et c'est ce qui a causé l'échec des points d'arrêt. Vous voulez qu'il regarde le dossier Bin actuel de votre projet.
J'ai eu ce problème lorsque, sur un client, où - pour chaque solution d'application - ils ont copié la plupart des assemblys partagés dans un dossier " References ", puis les a ajoutés à la solution en tant que " Eléments de la solution " et en tant que " Projet "dans la solution.
Je ne sais pas encore pourquoi, mais certains d’entre eux étaient déboguables, d’autres pas, même si dans les paramètres de référence des assemblys, les chemins complets corrects étaient spécifiés.
Ce comportement imprévisible me rendait folle :)
J'ai résolu ce problème en supprimant tous les assemblys du dossier " References " pour lesquels il existait des projets avec code source et en gardant une très bonne trace des informations de version pour assemblées partagées.
Il est important de noter ce fait pour ne pas être une réponse, mais ce problème de points de rupture non touchés, pour moi, vient de se résoudre. Après des heures de suppression de fichiers temporaires, de redémarrage, de réinstallation, d’archives avec les paramètres de débogage en vain, cela a tout à coup commencé à fonctionner. J'étais au bord de la folie quand, sans aucune raison, nous avons atteint un point de rupture. J'adore les insectes incohérents, moi.
J'ai eu un problème similaire, sauf que mon problème était idiot - j'avais 2 instances du serveur Web intégré fonctionnant sous 2 ports différents ET j'avais mon projet -> propriétés -> web -> "URL de démarrage" pointant vers un port fixe mais l'application Web ne fonctionnait pas réellement sous ce port. Donc, mon navigateur était redirigé vers "l'URL de démarrage" qui faisait référence à 1539 mais l'instance de code/débogage fonctionnait sous le port 50803.
J'ai changé le serveur Web intégré pour qu'il fonctionne sous un port fixe et j'ai également ajusté mon "URL de démarrage" pour utiliser ce port. projet -> propriétés -> web -> section "Serveurs" -> "Utiliser le serveur de développement Visual Studio" -> port spécifique
Veuillez vérifier les propriétés Web du projet Web (Asp.Net) hébergeant votre silverlight xap. Accédez au projet Web Hébergement de votre silverlight xap -> Propriétés -> Web -> Section Débogueurs -> Assurez-vous que la case silverlight est cochée.
J'ai essayé beaucoup de choses. Ce qui a fonctionné pour moi J'ai créé l'application Silverlight "Définir comme projet de démarrage" en cliquant avec le bouton droit de la souris sur le projet. Ensuite, j'ai essayé de l'exécuter (ce qui a évidemment échoué car il reposait sur RIA Services sur un serveur Web qui ne fonctionnait pas), puis j'ai réinitialisé le projet Web en tant que projet de démarrage .. et hé hop ... tout fonctionne.
Un scénario possible est que si votre projet ASP fait référence à du code dans une application (plutôt qu’une dll), les symboles ne seront pas chargés.
J'ai dû remplacer temporairement l'application référencée par une bibliothèque de classes pendant le débogage du code.
Si vous rencontrez des problèmes avec les projets Silverlight, la solution peut être relativement simple. Selon mon expérience, dans de nombreux cas, les symboles de débogage ne sont pas chargés car les nouveaux fichiers ".xap" ne sont pas déployés dans un dossier temporaire (soit VS Cassini interne, soit IIS Express). Dans cette situation, une reconstruction complète ou la réinitialisation des paramètres de VS ne vous aidera pas. La solution la plus simple consiste simplement à supprimer les fichiers Internet temporaires de votre navigateur. Si vous utilisez IE pour le développement et les tests Silverlight, je vous recommande d'activer l'option "Supprimer l'historique de navigation à la sortie" afin de ne pas avoir de tels problèmes à l'avenir.
Parfois, cliquez avec le bouton droit de la souris sur le point d'arrêt -> Emplacement -> en cochant la case Autoriser le code source à être différent de la version d'origine.
[EDIT]: Parfois, la reconstruction de la solution entière fonctionne également.
Il s'agit d'un problème courant si le débogage est désactivé par l'application et qu'il est souvent rencontré si vous avez plusieurs transformations sur le fichier web.config ... Une solution consiste à accéder à Build> Configuration Manager et à s'assurer que la configuration Debug est prêt pour le démarrage ... Assez commun de tester une transformation à l’autre, et donc de perdre sa capacité à se casser à des points spécifiques.
C’est un fil utile, une liste de vérification des solutions à apporter à ce problème pernicieux. Pour moi, celui qui fonctionnait était de passer à IE. Il m’a fallu un certain temps pour comprendre, car j’utilisais déjà IE, que j’avais défini les propriétés Web du projet, de sorte que l’action de démarrage consistait à démarrer un programme complet.
C:\Program Files (x86)\Internet Explorer\iexplore.exe
avec les arguments en ligne de commande
http: // localhost/MyProject -private
J'avais besoin de l'indicateur -private pour arrêter IE la mise en cache du swf sur lequel je travaille. Revenir à "page spécifique" de "démarrer programme externe" a corrigé le problème "aucun symbole n'a été chargé" pour moi.
Cette réponse n'est pas spécifiquement liée à Silverlight mais à l'erreur générale: le point d'arrêt ne sera pas atteint pour le moment. Aucun symbole n'a été chargé pour ce document. Une erreur de Noob est que le projet n'est pas défini comme débogage dans le gestionnaire de configuration. Ça vaut le coup
J'ai pris le chemin le plus facile, en fait dans ma solution à projets multiples, y compris une bibliothèque de classes, un problème avec un fichier .dll créé par ce projet de bibliothèque de classes ne me permettait pas d'avoir des points d'arrêt lors de l'exécution, car il ne générait pas Pour une raison quelconque, je construis séparément ce projet et référencé sa sortie .dll et maintenant les points d'arrêt sont fonctionnels
Pas sûr, peut-être que cela vous aide; sinon vous êtes quelqu'un de nouveau comme moi simplement parce que cela a fonctionné pour moi :)
Cette erreur peut également survenir lors du débogage distant si vous ne déboguez pas l'exécutable le plus récent. Lorsque vous êtes en train de déboguer à distance, n'oubliez pas de passer par le nouveau code sur la machine distante après avoir (re) construit sur votre machine de développement locale!
Je débogue en attachant à IIS. J'ai saisi le web.config de production pour certains nouveaux paramètres et j'ai oublié de mettre à jour le web.config pour permettre le débogage.
Assurez-vous que l'élément a le paramètre de débogage sur true. En d'autres termes:
<compilation defaultLanguage="c#" debug="true" targetFramework="4.0">
Ce que j'ai fait pour résoudre ce problème se trouvait dans la page où mon point d'arrêt ne frappait pas, j'ai sélectionné le dossier> ajouter un élément existant, puis sélectionné l'élément dans son chemin de sauvegarde. Cela a permis au point de rupture de commencer à fonctionner.
J'ai eu ce problème, mais dans mon cas, c'était à cause d'un chargement de module retardé que j'essayais de déboguer. J'avais un DLL lié à mon projet principal et le DLL était ce que j'étais en train de déboguer. La DLL n'a été appelée que lorsque certaines fonctions de l'application principale ont été appelées. VS2010 n'a donc pas chargé le module tant que ces fonctions n'ont pas été appelées.
Lorsque j'ai démarré le projet, j'ai reçu ce message, mais au moment de l'exécution de la fonction, le débogueur avait chargé le module et les informations de débogage associées.
Ce fil m'a beaucoup aidé: http://geekswithblogs.net/dbutscher/archive/2007/06/26/113472.aspx