J'avais une solution multi-projets que je construisais dans Visual Studio 2013 et tout fonctionnait bien, mais maintenant que j'ai migré vers Visual Studio 2015, je ne peux plus atteindre les points d'arrêt en mode débogage pour les projets exécutés comme projet principal. Projet de démarrage dans la page Propriétés du projet. Auparavant, je pouvais cliquer sur les autres projets et choisir Debug -> Start New Instance. Je reçois le message d'erreur The breakpoint will not currently be hit. No symbols have been loaded for this document.
. J'ai essayé beaucoup de choses trouvées sur Google, notamment:
Alors qu'est-ce qui me manque ici? Pourquoi ne puis-je plus déboguer les autres projets?
Je n'ai jamais compris ce qui s'est passé, mais j'ai fini par construire un tout nouveau projet et juste importer les fichiers, et tout fonctionne maintenant.
J'ai eu un problème similaire lorsque j'ai créé une nouvelle configuration de construction. Après avoir parcouru les paramètres de VS2015, j'ai remarqué qu'il n'y avait pas de fichiers * .pdb dans la sortie de ma construction. De toute évidence, le débogage ne fonctionnerait pas s'il y avait des fichiers * .pdb.
Le correctif pour moi était d'aller dans les propriétés de chaque projet -> page 'build' -> cliquez sur le bouton "avancé" en bas de la page -> Dans la section "Sortie" de la boîte de dialogue, j'ai défini "informations de débogage" sur " plein".
Fondamentalement, j'ai créé une nouvelle solution et projet et copié toutes les propriétés de génération dans la solution pour que le débogueur ne s'arrête plus aux points de rupture. En plus du paramètre ci-dessus, j'ai également modifié le paramètre suivant pour qu'il corresponde aux paramètres de débogage par défaut:
J'ai résolu ce problème lorsque coché Options-> Débogage-> Général-> Supprimer l'optimisation Jit lors du chargement du module. Auparavant, j'avais également décoché Outils-> Options "Projets et solutions" "Construire et exécuter" "Construire uniquement les projets de démarrage et les dépendances lors de l'exécution". Je ne sais pas si cela a une raison pour laquelle cela fonctionne après la suppression de jit est décochée.
Ma situation était que j'ai activé "Optimiser le code" dans les propriétés du projet.
L'exécution de la commande VS Invite en tant qu'administrateur en tant qu'exécution de la commande: devenv /setup
a résolu ce problème pour moi.
Le débogueur n'a pas atteint les points d'arrêt de mon application ASP après avoir migré de mon ancien système vers mon nouveau. J'ai oublié de configurer dans IIS pour le débogage.
Pour configurer IIS pour le débogage:
Cela m’a rendu fou, jusqu’à ce que j’ai réalisé dans une autre solution que j’étais sur le point de publier la configuration, de la remettre au débogage.
Ce n'est probablement pas votre réponse particulière, mais je pensais la partager "au cas où" quelqu'un d'autre se laisserait distraire par quelque chose d'évident!
Dans mon cas, je viens de changer le réglage de mon mode de fonctionnement.
Avant, j’utilisais le mode de fonctionnement "release":
Et maintenant, j'utilise le mode de fonctionnement "débogage":
Je viens de résoudre ce problème pour l'un de nos développeurs front-end. Cela peut ou peut ne pas s'appliquer à vous. Nous utilisons IIS Express pour le débogage local et son processus s’est déconnecté du processus correct lors du débogage.
Pour résoudre ce problème, j'ai vérifié l'ID de processus auquel il était associé selon IIS Express (cliquez avec le bouton droit de la souris sur l'icône IIS dans la barre des tâches, sélectionnez Afficher toutes les applications, vérifiez le PID répertorié pour l'application). Je l'ai ensuite associé au processus approprié (avec la solution s'exécutant dans VS, cliquez sur Déboguer dans la barre d'outils, sélectionnez attacher au processus, recherchez le processus approprié à l'aide du PID obtenu ci-dessus dans IIS Express). J'espère que ça aide quelqu'un.
Je n'ai jamais pu le faire fonctionner avec les méthodes ci-dessus et je suis finalement revenu à VS 2013 pour la solution qui fonctionnait bien. Il est très troublant de constater que le VS2015 ressemble beaucoup au VS2005 quand il est passé du robuste VS2003.
J'espère que 2017 résoudra ces incohérences.
Vous pouvez tout laisser tel quel, prenez simplement en charge les éléments suivants:
Dans mon cas, je n'ai pas pu déboguer, car j'avais des points d'arrêt définis dans le fichier temporaire du contrôle de source lors de l'analyse de l'historique du fichier au lieu du fichier réel dans la solution.
Mon projet était une application Web MVC et, lorsque j'exécutais le projet avec le débogueur, un nouvel onglet s'ouvrait dans le navigateur et me redirigeait vers la page de connexion. Mais dans un autre onglet, j'avais identifié un utilisateur qui pouvait tout faire, mais il ne touchait pas les points d'arrêt, même si j'avais du mal à rafraîchir la page. Et chaque fois que je fermais l’onglet récemment ouvert qui redirigeait vers la page de connexion. Une fois, j’ai fermé l’ancien onglet avec l’utilisateur connecté et effectivement connecté à nouveau à l’application dans l’onglet récemment ouvert. Ensuite, il a commencé à frapper les points de rupture.
J'espère que cela aide quelqu'un. Si vous exécutez du code sur votre ordinateur local sous IIS, vous devez associer votre solution au processus w3wp.exe. Donc, sélectionnez votre projet, allez dans le menu debug-> attach to process et dans la liste vous devriez voir w3wp.exe
Maintenant, si vous ne voyez pas w3wp.exe, cochez la case Afficher tous les processus ou allez dans votre gestionnaire IIS et parcourez votre site Web afin d'exécuter réellement l'instance w3wp.exe.
Le redémarrage de Visual Studio a fonctionné pour moi.
Je faisais également face à ce problème, mais après Visual Studio 2015 Update 1, il est maintenant corrigé.
https://www.visualstudio.com/en-us/news/vs2015-update1-vs.aspx