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 obtenu le 'Le point d'arrêt ne sera pas atteint actuellement. Aucun symbole n'a été chargé pour ce document. ' message à apparaître dans l'EDI, mais cela 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 de Visual Studio
• supprimé tous les fichiers de chaque dossier \ Temporary ASP.NET Files (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 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 suo de la solution
• 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 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 nouvelle application Web dans IIS
• changé la version Framework de chaque projet de 3.5 à 4.0
• Ouverture de la solution sur ma deuxième machine => même comportement
• Microsoft Connect a exploré les bogues / problèmes similaires
• A 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 des fichiers ASP.NET temporaires, 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 que vous devez déboguer.

J'ai eu le même problème et après avoir recherché sur Google, j'ai trouvé deux solutions typiques pour cela:

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

2. Redémarrez Visual Studio et supprimez tous les dossiers bin et obj.

Mais rien de tout cela n'a fonctionné pour moi . Ensuite, quelqu'un a mentionné un fil pour essayer d'utiliser IE comme navigateur à la place. Cela a permis au débogage et aux points d'arrêt de fonctionner à nouveau!

Éditer:

Plus tard, j'ai eu du mal avec IE9 qui ne fonctionnait pas, car il s'attache au mauvais processus. Au lieu de s'attacher manuellement au processus IE correct à chaque fois, j'ai trouvé une astuce intéressante :

• 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éfinir IE comme navigateur par défaut (n'affectera que le choix de navigateur de Visual Studio)

Maintenant, Visual Studio lancera IE lors de l'exécution du projet .Web et s'attachera au processus correct. Ç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.

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

C:\dev\MyApplication\bin 

mais Visual studio débogue de

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

Remarque - pour diverses raisons, je fais mon 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-à C:\dev\MyApplication- dire ci - dessus) est le répertoire physique configuré pour l'application Web - cela 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-à C:\dev\MyOtherApplication- dire ci - dessus) est le répertoire dans lequel svcse trouvent vos fichiers, généralement le même répertoire que votre csprojfichier de projet.

Le problème pour moi s'est avéré que la case Propriétés-> Build-> Optimiser le code avait été activée dans la configuration de débogage. Désactivé, reconstruit et le débogage ont fonctionné normalement.

La raison de ce à quoi vous avez dû faire face 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 créée avec la version actuelle du code pour le débogage sans (re) construire.

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

Pour vous assurer que le problème n'est pas le vôtre, 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 j'ai dû cliquer avec le bouton droit sur le projet et sélectionner "nouvelle instance de débogage". Je n'ai eu besoin de faire cela qu'une seule fois, puis après cela a fonctionné normalement.

Cette erreur se produit de temps en temps pour moi et je peux toujours la retracer aux paramètres du projet pour l'assemblage concerné. Vous n'avez pas à "attendre" jusqu'à ce que votre code ne respecte pas un point d'arrêt ou jusqu'à ce que vous définissiez le point d'arrêt, pour savoir quels assemblys ont des symboles chargés.

Lorsque vous exécutez un projet en mode débogage, il répertorie dans la fenêtre de sortie quels assemblages ont des symboles chargés comme 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 donc comparer les paramètres du projet pour cet assemblage à ceux d'un autre assemblage qui a réussi à charger des symboles, afin de comprendre pourquoi certains chargent et d'autres ne chargent pas de symboles.

«Pour moi» cependant, «chaque» fois que cela se produit, c'est parce que les informations de débogage ne sont pas créées. J'ouvre donc Project Properties> Build> Advanced dans un projet (C #).

Donc, pour Basd.Core.Data.dll ci-dessus, c'est-à-dire sans symboles, 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:

Je produis donc des informations de débogage dans le dernier projet et non dans le premier, d'où ma capacité à atteindre le point d'arrêt 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 .dll donné car il pourrait bien être obsolète et donc pas récupéré par Visual Studio en tant que fichier de symboles valide pour le .dll vous essayez de passer à travers.

Notez également que la modification des configurations de build peut modifier les paramètres d'informations de build et d'où les symboles sont extraits.

(Je me rends compte dans ce cas que je suis en mode Release mais la méthode s'applique toujours)

Goto Project Properties -> Build -> Advanced ...

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.

Déboguer -> Attacher au processus ->
choisir Déboguer ces types de code: option ->
sélectionner Managed v3.5, v3.0, v2.0 ou Managed v4.5, v4.0

Je viens de résoudre ce problème selon Deploying Silverlight Applications . (Cette réponse est un double 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 / démarrage. Il s'agit d'un problème de référencement - il 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é doit être copiée dans le dossier bin du projet de référence afin de déboguer. Pour les bibliothèques de classes, cela se produit lorsque vous cliquez avec le bouton droit 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 «Applications Silverlight» à 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 xapfichier 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 se trouvent dans 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 j'ai tout essayé : nettoyé les DLL, enquêté sur la liste des modules, désactivé "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 peut-il pas simplement m'avertir qu'il ne fonctionne pas "en tant qu'administrateur"? Cela me ferait gagner quelques heures de travail.

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

Eu le même problème

Pour une raison quelconque, l'une des DLL était enregistrée dans le GAC, par conséquent, elle avait toujours une version 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 utilisent Visual Studio 2008, pas Visual Studio 2010 et 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 l'attachant au processus w3wp.exe plutôt qu'en utilisant le serveur de développement ASP.NET pour le débogage (commencez par le débogage), cela peut être votre problème:

Il est possible que Visual Studio fasse toujours référence à un fichier de symboles (fichier utilisé pendant le 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 corriger:

Arrêtez simplement le débogage dans Visual Studio, redémarrez l'application Web et rattachez-le au processus. Ensuite, les points d'arrêt devraient passer du jaune (lorsque vous voyez cette erreur) au rouge à nouveau.

========================

Plus de choses à essayer (nouvelle situation trouvée aujourd'hui):

Faites chaque puce dans le lien ci-dessous UNE À LA FOIS, mais répétez mes étapes ci-dessous avec chacune que vous essayez.

http://carnotaurus.philipcarney.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same

1.) Arrêtez le débogage (appuyez sur l'icône carré rouge) dans Visual Studio
2.) Nettoyez la solution
3.) Construisez la solution
4.) [INSÉREZ LES INSTRUCTIONS DE LA BULLE ICI]
5.) Outils> Attacher au processus (ou commencez le débogage)
6.) Démarrez le programme auquel vous vous attachez et exécutez-le de sorte que votre code soit frappé

6 ont expliqué:

Si vous vous attachez à nunit.exe, ouvrez NUnit et exécutez un test pour que votre point d'arrêt soit atteint

Si vous vous attachez à w3wp.exe (site IIS), ouvrez votre site dans le navigateur et accédez à la page qui atteindra votre point d'arrêt

ÉDITER:

Aujourd'hui, j'ai remarqué que si vous essayez de déboguer sur un projet qui n'est pas défini comme projet de démarrage, cela le montrera. Lorsque vous vous attachez à votre processus w3wp.exe, il pense que son débogage sur le projet qui est défini comme projet de démarrage. Pour résoudre ce problème, faites un clic droit sur le projet d'application Web et choisissez «Définir comme projet de démarrage». Essayez ensuite 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 fait référence à d'autres projets dans votre solution. Les points d'arrêt des autres projets ne sont pas touchés.

Solution rapide: lorsque vous créez votre solution, recherchez dans le chemin de sortie Build (généralement bin \ Debug) le projet de démarrage. Regardez les fichiers DLL et PDB des projets auxquels vous faites référence. Assurez-vous que leur dernière date de modification est la date à laquelle vous avez créé votre solution pour la dernière fois. Si ce n'est pas le cas, copiez-les du chemin de sortie de génération pour chaque projet dans vos projets de démarrage Chemin de sortie de génération. Par exemple:

Le projet A a Main. Il fait référence au projet B. Vos points d'arrêt ne sont pas atteints dans le projet B. Copiez le fichier DLL et PDB du chemin de sortie de génération du projet B vers le chemin de sortie de construction du projet A. Exécutez ensuite votre solution. Le point d'arrêt sera désormais atteint.

Vous devez maintenant comprendre pourquoi le projet A ne copie pas le fichier DLL et PDB du projet B. Les réponses ici couvrent la plupart des scénarios. Un scénario non touché 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 corrigé cela, le problème a disparu et je n'ai plus eu à copier les fichiers DLL et PDB.

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

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é à nouveau aux références de service
5. Nettoyez la solution et reconstruisez-la.

Pour résoudre ce problème dans Web.config, je devais simplement ajouter debug="true"

  <system.web>
    <compilation targetFramework="4.0" debug="true">

Ce qui m'a aidé à trouver cette solution a été de regarder les fenêtres des modules lors du débogage et de constater que pour mes DLL ASP.NET chargées, j'avais: le binaire n'a pas été construit avec des 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 de la solution: -

1. Faites un clic 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 sous-plat
4. Cochez la case "Build" pour chaque projet que vous souhaitez déboguer

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

D'accord, c'est parti:

(Dans une "application silverlight": veuillez d'abord vérifier que silverlight est vérifié dans "web" dans les "propriétés" de votre projet de serveur - Si cela ne l'a pas résolu, essayez ceci ci-dessous)

La première fois, 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 "activez le pas de source du framework .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 où se trouvent les symboles:

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 "symboles", trouvez le bouton "cache de symboles vide" et cliquez dessus.

Ouvrez l'URL de l'application Web à partir du navigateur, puis dans VS.Net IDE, utilisez Tools -> AttachtoProcess

puis attachez-le à aspnet_wp.exe.

Le débogueur commencera à fonctionner

J'ai dû désinstaller manuellement toutes les instances du .dll du registre et toutes les instances du .dll de mon lecteur local. Désinstallé / réinstallé mon application et maintenant je frappe des points d'arrêt! J'ai perdu une demi-journée à faire ça :(.

J'ai essayé de renommer le .pdbfichier dans le obj\debugdossier et j'ai fait une solution propre et reconstruit.
Il a créé un nouveau .pdbfichier et j'ai pu 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 (sur 7 projets C #). La solution se compilait 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> Update-Package Newtonsoft.Json

Pour mon application WPF, j'ai supprimé le dossier de l'application, j'ai à nouveau récupéré le contrôle de source et reconstruit. Tous les points d'arrêt fonctionnent très bien maintenant.

Essayez de définir Silverlight Application Project comme projet de démarrage: faites un clic droit sur le projet -> 'Définir comme projet de démarrage. Appuyez ensuite sur F5 et voyez 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 apportez des modifications à l'application silverlight

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 Release. Lorsque les résultats de la construction ont été placés dans un dossier de marchandises, ces DLL de version remplaçaient les DLL de débogage.

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

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

et pas

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

J'ai eu ce problème même chez un client où - pour chaque solution d'application - ils ont copié la plupart des assemblys partagés dans un dossier " Références ", puis les ont ajoutés à la solution à la fois en tant qu '" éléments de 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 non, même si dans les paramètres de référence pour les assemblys, les chemins d'accès complets corrects ont été spécifiés.

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

J'ai résolu cela en supprimant tous les assemblys du dossier " Références " pour lesquels il y avait des projets avec du code source, et en gardant une très bonne trace des informations de version pour les assemblys partagés.

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 s'exécutait 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 fonctionnait 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 également. projet -> propriétés -> web -> section "Serveurs" -> "Utiliser Visual Studio Development Server" -> port spécifique