Échec de liaison du point d'arrêt - Visual Studio 2015
Je viens de mettre à niveau Visual Studio 2013 vers 2015 et j'ai maintenant des problèmes avec les points d'arrêt.
C'est un coup ou un coup raté où les points d'arrêt fonctionneront réellement et si j'en définit un pendant le débogage, j'obtiens l'erreur
Le point d'arrêt n'a pas réussi à se lier.
Toute aide serait appréciée. Je suis sur le point de renoncer à 2015 et de revenir en arrière.
J'ai eu le même problème, mais une solution différente ..__ Veuillez noter que j'ai mis à jour à la mise à jour VS 2015 1 et le problème est toujours là.
Dans les éditions précédentes de VS, le démarrage du débogage entraînait automatiquement une construction en mode débogage. Mais avec VS2015, ce n'est pas le cas.
Ainsi, si votre dernière version était en mode de publication et que vous essayez de déboguer, le point d'arrêt ne fonctionnera pas.
Vous devez commencer par créer manuellement en mode débogage, puis lancer le débogage.
J'ai eu le même problème.
Je l'ai résolu en désactivant l'option "Optimiser le code" dans l'onglet Construire des propriétés du projet.
Cela peut sembler anodin, mais après de nombreuses critiques concernant les mêmes problèmes que ceux que vous avez mentionnés, j'ai découvert que ma version était configurée pour "libérer" au lieu de "déboguer" lorsque j'ai essayé de déboguer. "corrigé, et je pouvais définir des points d'arrêt comme d'habitude
J'ai eu un problème similaire avec des points d'arrêt échouant à se lier, ainsi que certaines variables locales non évaluées dans la fenêtre Locals. Ce qui a finalement été résolu, c’était l’activation de l’option «Supprimer l’optimisation JIT lors du chargement du module (géré uniquement)» dans l’onglet Options-> Débogage-> Général. Une fois que j'ai défini qu'il était capable de se lier sans problème.
J'ai eu ce problème. J'ai exécuté une session de profilage de performances qui a modifié le fichier Web.config avec les paramètres du moniteur de performances. Cela m'a cassé la capacité de m'arrêter aux points d'arrêt. Lorsque j'ai rétabli le fichier Web.config d'origine (les paramètres de Performance Profiler ont été supprimés), les points d'arrêt ont recommencé à fonctionner.
J'ai eu le même problème hier. J'ai utilisé la fonctionnalité "Solution propre" et cela m'a aidé.
Je lance la performance sur ma solution et cela a ajouté cela à mon web.config
<compilation debug="true" targetFramework="4.5" assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
le assemblyPostProcessorType est le problème, je l'ai supprimé et cela a résolu mon problème
la solution consiste à désactiver l'optimisation de la conception.
Project Properties> Build> Advanced Compile Options> Enable Optimizations
Changer le mode Release en Debug, dans mon cas, cela a résolu mon problème.
Je n’ai pas changé le réglage 'optimiser', mais en me basant sur d’autres réponses, je
- Définir l'Explorateur de solutions pour afficher tous les fichiers du projet
- Supprimé les dossiers masqués et de débogage
- Effectuer un «nettoyage» sur le projet
- Effectué 'Rebuild' sur le projet
Jusqu'à présent, cela a résolu le problème pour moi. On dirait que la mise à jour vers VS2015 Update 2 a eu quelques conséquences sur mon système.
ÉTAPE 1, écarter l'évidence:
- Compiler en mode débogage.
- Essayez de nettoyer la solution avant de définir le point d'arrêt.
- Accédez au dossier de débogage et supprimez le fichier .pdb de [Votre application].
- Ensuite, créez ou reconstruisez votre application.
- Accédez au dossier de débogage et vérifiez que vous disposez d'un nouveau fichier .pdb [Votre application ].
- Ensuite, essayez de définir votre point de rupture.
ÉTAPE 2 Pour les projets C++:
Vérifiez les propriétés de projet suivantes:
- Format C++/Général/Informations de débogage: Base de données du programme.
- C++/Optimisation: désactivé.
- Bibliothèque C++/Code/Runtime: Debug multi-thread.
- Lieur/débogage/génération d'informations de débogage: oui.
- Lieur/débogage/base de données du programme Generate: $ (TargetDir) $ (TargetName) .pdb.
- Lieur/fichier manifeste/générer manifeste: Non.
- Éditeur de liens/Fichier manifeste/Autoriser l'isolement: Non.
- Éditeur de liens/IDL incorporé/Ignorer les IDL incorporés: Oui.
Répétez l'étape 1
Vous pouvez essayer d’ajouter __debugbreak (). Cette déclaration doit aller dans votre fichier source où vous voulez casser.
ÉTAPE 2 Pour les projets C #:
- Dans les propriétés du projet, le code de construction/général/optimisé doit être Désactivé.
- Dans les paramètres IDE] Débogage/Options et Paramètres/Débogage/Général Supprimer JIT Optimisation lors du chargement du module (Géré uniquement): Activé
- Répétez l'étape 1
Essayez d'ouvrir votre solution sur d'autres machines. Si vous pouvez lier un point d'arrêt sur une machine différente, cela peut signifier qu'il y a un problème avec votre VS ou votre système d'exploitation.
ÉTAPE 3, Assurez-vous que votre VS est à jour:
De tels problèmes ont été signalés dans les versions VS2013 RTM et VS2015 Update 1 et Update2.
Dans VS, allez dans Outils/Extensions et mises à jour/Mises à jour/Mises à jour du produit et voyez quelle version vous utilisez. Si une mise à jour est nécessaire, elle apparaîtra ici.
ÉTAPE 4, Assurez-vous que votre système d'exploitation est à jour:
Enfin, si vous exécutez un système d’exploitation Windows 10, un problème a été signalé concernant ce problème, qui existait dans la version 14251. Ce problème a été résolu dans la version 14257 (et ci-dessus).
Nettoyez la solution complète avant d'essayer l'une des autres solutions. Après avoir essayé à peu près tout ce qui avait été dit dans les réponses précédentes et relancé Visual Studio à plusieurs reprises, le simple nettoyage de la solution a fait l'affaire!
Je viens de rencontrer un problème similaire et aucune des réponses ici ne résout le problème que je rencontrais. Contrairement à la question, cependant, je ne reçois jamais aucun message disant que la liaison a échoué. Le point d'arrêt ne frappe jamais. Espérons que cela sera utile à quelqu'un dans le futur qui se cognera contre WCF.
TL/DR:
Dans le message SOAP, un enregistrement contenant des données incorrectes empêchait le point d'arrêt d'être touché.
Histoire complète:
J'ai un service WCF basé sur WSDL d'une autre équipe. Ce n'est pas ma définition, pas de contrôle ... Je reçois des messages de cette autre équipe via ce service. Dans mon cas, je reçois des messages, je peux les consigner dans la table des journaux de messages de la base de données (avant que la méthode de service ne soit appelée), la méthode de service est apparemment appelée (peut-être pas) et le serveur répond avec a 202 Accepté. La communication fonctionne, sauf qu'aucune donnée n'est enregistrée dans la base de données lors de l'appel de la méthode.
Depuis que le service renvoie une réponse positive, j'ai exclu les problèmes liés à http et au transport.
J'ai donc lancé VS2015 pour déboguer le service. Le message en question est large mais bien dans les limites de ce à quoi je m'attendais. Je mets un point d'arrêt sur la première ligne de la méthode de service et envoie le message volumineux, mais le point d'arrêt ne frappe jamais. J'ai essayé un message plus petit qui, je le savais, fonctionnait sur la même instance d'exécution et le point d'arrêt a été correctement touché. Donc, tout dans la configuration semblait bien. Je pensais qu'il y avait peut-être quelque chose dans la taille du message.
J'ai essayé tout ce que j'ai pu trouver - en m'assurant d'être dans une configuration de débogage, de nettoyer et de reconstruire, en liant manuellement le débogueur au processus w3wp (lequel était déjà VS), en utilisant Debugger.Break() au lieu d'un point d'arrêt, en configurant plusieurs projets de démarrage, en déchargeant mon test projet pour que le projet de service soit le seul à mettre à jour .NET, à redémarrer VS2015, à redémarrer, à basculer de Local IIS à IIS Express et inversement, à recréer le service avec le dernier fichier WSDL garanti. Rien ne comptait. Le point d'arrêt n'a jamais été touché.
J'ai fini par éliminer les enregistrements du message volumineux un par un jusqu'à ce que je trouve un seul enregistrement contenant de mauvaises données. Dans mon cas, c’était un enregistrement qui n’avait aucune valeur pour 2 champs DateTime. Lorsque j'ai créé et envoyé un message contenant uniquement cet enregistrement, le point d'arrêt n'a pas été touché. Quand j'ai fourni des valeurs pour ces 2 champs DateTime et envoyé le même message (fixe) dans le point d'arrêt déclenché comme prévu.
Toutes les exceptions CLR étaient activées et rien n’était renvoyé, à part le manque de fichiers .pbd, ce qui m’était égal. WCF a heureusement envoyé la demande avec un mauvais enregistrement. Je ne dis pas que la WCF n'aurait pas dû l'envoyer en fonction des contrats, mais simplement que le mauvais enregistrement a empêché le point d'arrêt d'être atteint.
J'ai eu le même problème, mais je n'avais pas réalisé que "Debug" avait été remplacé par "Release" dans la barre d'outils de débogage (généralement directement sous le menu). Donc je l'ai mis à "Debug" cela a fonctionné.
Bien que ce soit une version beaucoup plus tardive (VS2017), j'ai eu ce problème avec les projets C #. Essayé de nettoyer, de reconstruire, de redémarrer Visual Studio, etc.
Ce qui a résolu le problème, c'était la fermeture de Visual Studio et la suppression du dossier .vs, un dossier caché situé dans le répertoire de la solution. La suppression du dossier .vs ne devrait pas vous causer de problèmes, mais vous devrez réinitialiser votre projet de démarrage.
J'ai essayé tout ce qui est suggéré ici. Finalement, j'ai défini la "Page spécifique" dans Propriétés du projet -> Web sur mon URL de démarrage locale, ma page et mon paramètre de requête. A fait un nettoyage et une reconstruction en mode débogage et cela a frappé mon point d'arrêt.
J'ai rencontré les erreurs de points d'arrêt de liaison aujourd'hui. Et j'ai résolu mon problème en faisant des belows.
Si toutes vos configurations de débogage ne sont pas correctes, vous ne pouvez pas résoudre le problème avec Belows.
- Projet propre
- Si le chemin de sortie est différent du dossier bin, remplacez-le par le dossier bin (c'est la règle la plus importante)
- Reconstruire
Peut-être que cette solution aide quelqu'un.
Dans mon cas, un nouveau fichier web.config a été créé après l’utilisation de Profiler. La restauration de web.config à la version précédente a résolu ce problème. C'était une application Web VS2015 C #.
Les points d'arrêt VS ne peuvent pas être liés sur des méthodes asynchrones.
J'ai eu un agent App Dynamics installé qui a causé cela. Supprimez cela et vous êtes prêt à partir.
J'ai agité un poulet en caoutchouc sur ma machine de développement, j'ai dessiné le contour d'une étoile à la craie et cela a fonctionné. Avant de rire, cela n’est pas moins absurde que les autres solutions proposées pour ce bogue. Vous ne ferez pas comme si de rien n'était. Toutes les solutions proposées ici ne vont pas en rester là. Je pense que l'abandon de Visual Studio 2015 est le seul moyen pratique de l'éviter.
J'ai dû modifier le fichier web.config pour activer le débogage. Change ça:
<compilation debug="true" targetFramework="4.5.2" assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
à:
<compilation debug="true"/>
La nouvelle Mise à jour pour Microsoft Visual Studio 2015 Update 3 (KB3165756) a corrigé le problème de point d'arrêt pour lequel j'essaie d'inspecter les variables locales dans le code C # intégré dans des fichiers cshtml dans des applications ASP.NET Core.