Points d'arrêt Visual Studio non touchés
Je travaille avec un projet ASP.NET MVC qui semble avoir quelques problèmes lors de la liaison au processus IIS (w3wp.exe). J'exécute la solution et IIS 8.5 sur mon propre ordinateur local. Je ne pense donc pas que cela a un lien avec notre réseau. Ce qui est étrange pour moi, c’est que je peux atteindre les points d’arrêt avec n’importe quelle autre solution que je débogue localement.
Le problème que j’ai exactement, c’est que les points d’arrêt se transforment en cercles rouges et creux et ne sont jamais touchés. Habituellement, la solution à ce problème est un nettoyage/reconstruction de la solution, mais cela n'a pas fonctionné. J'ai confirmé que le code était mis à jour en ajoutant "throw new Exception" à une page et en veillant à ce qu'il affiche l'exception. Encore une fois, ce problème ne se produit qu'avec cette solution. Toute autre solution sur laquelle je lance le débogueur fonctionne correctement. J'ai également essayé de redémarrer le pool d'applications, le site Web, IIS et mon ordinateur.
Certains des articles que j'ai lus mentionnent que les programmes anti-virus peuvent empêcher un débogueur distant d'accéder au processus. Cependant, la configuration complète est contenue sur ma machine locale, donc cela ne semble pas être le problème. Cela me préoccupe toutefois un peu, car nous avons récemment embauché un nouveau responsable informatique qui a apporté de nombreux changements à la machine de chacun.
Un autre point à ajouter est unique dans cette application Web: la liaison dans IIS. La liaison est "*" afin de tirer parti de certaines fonctionnalités personnalisées liées aux sous-domaines.
En attendant, je continuerai à chercher une solution, mais si quelqu'un a une idée de ce qui pourrait empêcher cette solution de déboguer correctement, je l'apprécierais vraiment.
EDIT: solution trouvée suggérant de supprimer les fichiers temporaires ASP.NET. Pas de chance.
Résolu. En fin de compte être une configuration incorrecte sélectionnée dans le menu de débogage. Je l'avais commuté par erreur sur une configuration de version qui ne pouvait pas charger les symboles du document. Basculé sur une configuration de débogage et les points d'arrêt ont très bien frappé maintenant.
Pour ajouter à ce que Abacus a mentionné ci-dessous, il pourrait également s'agir d'une transformation web.config qui perturbe votre construction. Dans notre cas, nous avons des configurations de version qui suppriment l'attribut debug de la section de compilation de web.config. Vous trouverez ci-dessous une capture d'écran d'un exemple et de la liste déroulante des configurations de construction de Visual Studio.
REMARQUE: Assurez-vous également que votre plate-forme est correcte avec la configuration. Dans mon cas, Dev.Debug|Mixed Platforms ne construit pas correctement la solution mais Dev.Debug|Any CPU le fera.
Activer le 'Mode de compatibilité géré'. Allez dans Outils-> Options-> Débogage et activez le mode de compatibilité gérée.
Je sais que ce n’est pas le problème des PO, mais cela m’est arrivé dans le cadre d’un projet. La solution comportait plusieurs projets MVC et le mauvais projet avait été défini comme démarrage.
J'avais également défini la configuration du (des) projet (s) pour que le processus/débogueur ne démarre que et que je n'ouvre pas une nouvelle fenêtre de navigateur.
Donc, à première vue, il semble que le débogueur est en train de démarrer, mais le processus est incorrect. Vérifiez donc cela et gardez à l'esprit que vous pouvez également vous connecter à plusieurs processus.
Silly erreur qui m'a laissé me gratter la tête pendant environ 30 minutes.
J'ai eu du mal à toujours essayer de résoudre ce problème. Enfin c'est ce qui me l'a fait.
Sélectionnez Debug-> Options-> Debugging-> General
Cochez Activez le pas à pas source .NET Framework.
(C’est peut-être tout ce que vous devez faire, mais si vous êtes comme moi, vous devez également procéder comme indiqué ci-dessous. La solution ci-dessous corrigera également les erreurs lorsque votre projet charge des anciens assemblys/fichiers .pdb malgré la reconstruction et le nettoyage.)
Sélectionnez Outils -> Options -> Projets et solutions -> Construire et exécuter ,
Décochez la case à cocher " Construire uniquement les projets de démarrage et les dépendances sur Exécuter ",
Sélectionnez Toujours construire dans le menu déroulant " À l'exécution, lorsque le projet est obsolète ".
Faites un clic droit sur votre projet, puis cliquez gauche Propriétés et sélectionnez l'onglet Web .
Vérifiez si le bon serveur est sélectionné pour votre cas:
IIS Local
IIS Express
Accédez au menu Visual Studio:
Debug -> Attacher au processus
Et puis cliquez sur le bouton Select , comme dans l'image ci-dessous:
Assurez-vous ensuite que l'option "Déterminer automatiquement le type de code à déboguer" est sélectionnée, comme ceci:
J'ai eu le même problème dans un projet Xamarin.Forms. Le correctif consistait à convertir manuellement le PCL de .NET 4.6 en .NET Standard 2.0.
Pour Visual Studio Mac: assurez-vous de le faire pour chaque projet.
Dans Visual Studio 2017, vous devez vous assurer que vous n'êtes pas en mode de configuration finale.
- Ouvrez le menu de construction ddl
- Cliquez sur gestionnaire de configuration
- Passer de 'release' à 'debug'
Dans mon scénario, j'ai une application MVC et WebAPI dans une solution et j'utilise le protocole local IIS (non express).
J'ai également configuré les sites dans IIS en tant que domaines réels et modifié mon fichier hôte afin que je puisse taper le domaine réel et que tout fonctionne . J'ai également remarqué 2 choses:
Le débogage de code MVC fonctionnait parfaitement.
La fixation au processus a parfaitement fonctionné également. Juste au moment du débogage, cela n'a pas atteint le point d'arrêt de mon API.
C'était la solution pour moi:
Cliquez avec le bouton droit sur projet webapi> propriétés> Web> URL du projet.
Par défaut, il pointe sur localhost, mais puisque j'ai configuré le site dans IIS, j'ai oublié de modifier l'URL du domaine du site Web (c'est-à-dire au lieu de locahost, il devrait indiquer http: // {nom-domaine} /).
Le problème a été résolu en décochant la case
Propriétés> Construire> Optimiser le code
paramètre sur l’écran des propriétés de la page Web (sous Général).
Dans mon cas, le processus réel était différent du processus initial démarré.
Habituellement, nous lions les services hébergés par le biais du processus w3wp.exe. Dans mon cas, un processus personnalisé a été utilisé. Changer pour résoudre le problème.
Une dernière chose, passez de Release à Debug mode. En mode de publication, les fichiers PDB ne sont pas mis à jour avec les détails des points d'arrêt. Assurez-vous donc que vous déboguez votre application dans Debug mode.
Vous ne pouvez pas atteindre les points d'arrêt lorsque vous êtes connecté au processus IIS si vous ne vous êtes pas connecté à votre compte Microsoft dans VS2017.
Un de mes projets dans ma solution a été défini sur Release mode. Je l'ai changé en Debug mode, et les points d'arrêt frappent maintenant.
Si quelqu'un utilise Visual Studio 2017 et IIS et tente de déboguer un projet de site Web, voici ce qui a fonctionné pour moi:
- Joignez le projet de site Web à IIS.
- Ajoutez-le à la solution avec Fichier -> Ajouter -> Site Web existant ... et sélectionnez le projet dans le répertoire
inetpub/wwwroot. - Cliquez avec le bouton droit sur le projet de site Web dans l'explorateur de solutions et sélectionnez Pages de propriétés -> Options de démarrage.
- Cliquez sur Page spécifique et sélectionnez la page de démarrage (pour le service utilisez Service.svc, pour le site Web, utilisez Default.aspx ou le nom personnalisé de la page sélectionnée).
- Cliquez sur Utiliser un serveur personnalisé et écrivez
http (s): // localhost/(nom du site Web tel qu'il apparaît dans IIS)
par exemple: http://localhost/MyWebSite
C'est tout! N'oubliez pas de vous assurer que le site Web est exécuté sur IIS et que le site Web que vous souhaitez déboguer est sélectionné comme projet de démarrage (Cliquez avec le bouton droit de la souris sur>> Définir comme projet de démarrage).
Message original: Comment déboguer vos projets ASP.NET s'exécutant sous IIS
Si rien de ce qui précède ne fonctionne, vérifiez votre code. Parfois, la raison pour laquelle le point d'arrêt semble ne pas être atteint est due au bloc de code contenant le point d'arrêt qui n'est pas exécuté pour des raisons parfois fortuites.
Par exemple, l’oubli de "Handles Me.Load" m’a valu plusieurs fois lors du copier-coller de code:
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs)
--this block of code will not execute
End Sub
contre
Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Load
--this block executes
End Sub