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


331

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.


Ceci est un doublon, regardez [Cette page] [1], pour une réponse à votre question [1]: stackoverflow.com/questions/2155930/…
SuperKael

@CalebJares haha ​​j'ai rencontré ce problème aujourd'hui. il s'avère que je construisais / fonctionnais en mode release au lieu de déboguer.
theB3RV

Dans mon cas, la désactivation de Optimiser le code dans l'onglet Générer des propriétés du projet a résolu le problème.
Arash Motamedi

Réponses:


176

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.


Cela a fonctionné mais j'ai dû le faire plusieurs fois (VS 2010, serveur Web intégré, site Web)
MGOwen

17
J'ai plusieurs projets et je les démarre comme vous le dites. Certains d'entre eux sont des projets de bibliothèque de classes. Une fenêtre contextuelle d'erreur apparaît: "Un projet avec un type de sortie de bibliothèque de classes ne peut pas être démarré directement"
Muhammad Azeem

3
J'ai exactement le même problème que Muhammed a commenté. Le projet pour lequel VS ne charge pas de symboles est un projet de bibliothèque. Fait intéressant, une autre solution qui lie au même projet de bibliothèque n'a aucun problème à déboguer cette même bibliothèque!
Vivian River

1
Je ne pense pas que ce soit une réponse à la question. Il définit simplement plusieurs projets pour démarrer en même temps, au lieu d'un seul qui est typique. Si le projet est une classe Lib (dll), il affichera un message d'erreur indiquant qu'il ne peut pas être démarré. Qu'un projet soit ou non un projet de démarrage n'a aucune incidence sur le débogage.
Greg Gum

Dans mon cas, j'avais reconfiguré le site IIS exécutant mon projet pour pointer vers un dossier différent. D'une manière ou d'une autre, cela avait effacé le paramètre de solution indiqué ci-dessus ...? Il peut s'agir d'une erreur de contrôle de code source, mais je n'ai pas trouvé de modification du fichier .sln. Quoi qu'il en soit, la réinitialisation comme décrit a résolu le problème - espérons que la perspicacité aide quelqu'un.
brichins

79

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.


Merci, cela a juste fonctionné pour moi! Le seul problème est: je ne peux pas définir le navigateur à exécuter dans les fichiers de configuration (puis-je?), Alors maintenant je suis bloqué en tant qu'IE comme navigateur par défaut. Bah.
DanTheMan

1
Pour éviter d'avoir IE comme navigateur par défaut, j'ai modifié les paramètres de lancement dans le projet .Web pour exécuter IE avec le chemin d'accès comme paramètres de ligne de commande.
angularsen

Tu es incroyable. Je me bats avec ce problème depuis quelques jours. J'ai même réinstallé Visual Studio. Mon navigateur par défaut était Firefox, j'ai essayé Chrome. Cela ne m'a tout simplement pas traversé l'esprit d'essayer IE, quelle perte de temps. Merci pour l'info.
GaneshT

Mon commentaire précédent sur les paramètres de lancement ne doit pas être suivi lors de la résolution du problème, comme expliqué dans ma réponse modifiée. Utilisez simplement l'option "Page spécifique" par défaut, sinon je pense qu'elle peut être liée au mauvais processus.
angularsen

6
J'ai coché la case "Silverlight" sur l'onglet "Web" dans les paramètres du projet .Web. Maintenant ça marche. Merci!
Eugene Maksimov

54

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.


2
Peut-être, mais la réponse de Hans K a fonctionné pour moi. Je suppose qu'il y a plusieurs réponses selon la situation.
Bob Wintemberg

OK, mais comment savoir si cela se produit? Comment je le répare?
MGOwen

@MGOwen - dans votre configuration IIS, vérifiez l'emplacement physique du dossier virtuel contenant vos services et assurez-vous qu'il correspond au répertoire de sortie de VStudio.
Bevan

Oui, je travaillais également avec IIS, mais après le crash de VS, mon fichier de solution est devenu corrompu, j'ai donc dû le retirer de subversion à nouveau. Bien sûr, j'ai oublié qu'en faisant cela, il est revenu à l'utilisation du serveur VS webdev. Duh! Merci!
Fedor Steeman

3
Lorsque VS est confus, assurez-vous de revenir au profil de débogage. Cela m'a eu.
Christopher Stevenson,

46

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.


2
travaillé pour moi. Je ne sais pas vraiment pourquoi, le fait d’activer le «code d’optimisation» ne vous permettra tout simplement pas de casser sur {et}.
viggity

A aussi fonctionné pour moi! Merci!
bisand

1
Projet prêt à publier la version. Il y a toujours quelque chose qui n'est pas là.
Ian Warburton

Ça l'a fait pour moi! +1
Imdad

22

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


merci pour la tête en l'air .. bien sûr j'ai nettoyé / reconstruit la solution mais cela n'a pas aidé. Point 1: comment déboguer une autre application si je l'ai essayée sur un autre système? pareil pour le point 2. d'ailleurs, c'est RC et assez stable du tout .. merci quand même.
Christian Casutt

Je n'ai pas bien compris votre phrase "je l'ai essayé sur un autre système"!. Release Candidate ne signifie pas qu'il est exempt de bogues et vous ne perdrez rien si vous l'essayez. Si vous utilisez IE8, certaines personnes ont dit que cela pouvait être à l'origine du problème, vérifiez ceci: weblogs.asp.net/abdullaabdelhaq/archive/2009/06/01/…
Sameh Deabes

J'ai trouvé cela aussi: stackoverflow.com/questions/389290/… les gens ont suggéré des solutions trop molles là-bas. Jetez un œil au commentaire du point d'arrêt en ligne.
Sameh Deabes

OK je vois. ma phrase 'je l'ai essayé sur un autre système' => copié la solution sur une clé USB, supprimé tous les dossiers bin / obj, ouvert la solution dans VS.NET et essayé de la déboguer. résultat: même comportement => les points d'arrêt ne sont pas touchés .. merci pour l'autre lien, je vais le lire maintenant.
Christian Casutt

Clean + Rebuild ne met pas toujours à jour les fichiers .pdb. Ce que j'ai fait - je suis allé dans le dossier / Bin de mon application Web et j'ai supprimé manuellement tous les fichiers .pdb, puis reconstruit. A fonctionné comme un charme.
Dmitriy

21

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.


Très étrange. J'ai eu le même problème et l'ai googlé pendant 2 heures. Pour une raison quelconque, le module ne se chargeait pas lorsque je débogue (Debug -> Windows -> Module). Je viens d'essayer ces options et le débogage du boom a commencé à fonctionner. J'utilisais Vs2019
Rennish Joseph

18

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

Fenêtre de sortie

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:

pdboff

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:

pdbon

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)


1
Vous pouvez également vérifier quels symboles ont été chargés via la fenêtre Modules. Si vous accédez à Déboguer> Windows> Modules, il répertorie tous les modules et leur état de symbole. Pour ceux qui ne sont pas chargés, vous pouvez faire un clic droit dessus et cliquer sur "Charger les symboles". Il s'agit plutôt d'une solution à court terme et ne fonctionne que si elles apparaissent dans la liste pour commencer.
EF0

14

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

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


J'essayais d'attacher le débogueur au profil de version et cela a fonctionné pour moi!
imlokesh

1
Merci! "pdb-only" (plutôt que plein) était suffisant.
Greg Little

Que Dieu vous bénisse mon enfant.
Christopher D.Emerson


10

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 entrez la description de l'image ici


C'est le problème que j'ai rencontré. J'ai des projets en v4.5 et d'autres en v2.0 (ouais, je sais, je sais ...). Apparemment, ce paramètre n'est pas basé sur un projet, donc lorsque je l'ai défini dans un projet v4.5, j'ai dû le redéfinir lorsque je suis entré dans un projet v2.0.
L_7337

9

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.


9

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

8

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.


8

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


7

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


Vous voulez dire comment en est-il arrivé à cette situation? Ou comment l'ai-je supprimé?
Stikut

Comment l'avez-vous retiré? J'ai le même problème et je ne peux pas le résoudre. J'ai tout essayé alors j'espérais que c'était ma solution.
Gaui

1
J'espère que vous pourrez utiliser celui-ci: support.microsoft.com/kb/873195 À moins bien sûr que vous ayez une autre erreur
Stikut

6

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.


N'hésitez pas à voter pour la réponse si elle vous a été utile. :-) Je vais vous montrer ce que fait le vote.
MacGyver

J'ai voté pour votre réponse car elle a été utile. J'ai essayé un autre moyen mais c'est le vôtre qui m'a fait sortir. Merci +1.
Zaker

5

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.


Votre paragraphe 2 a résolu mon problème. L'un des projets de la solution se trouvait dans un répertoire bin différent du répertoire bin de la dll de démarrage.
BobRodes

4

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.

4

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.


3

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.


Cela a fonctionné pour moi, mais j'ai également dû changer tous mes projets de Release à Debug dans la colonne Configuration.
JoshYates1980

2

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.


2

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


2

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


2

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.


2

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


2

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.


1

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


1

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>


1

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.


1

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

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.