Échec de la liaison du point d'arrêt - Visual Studio 2015

Je viens de passer de Visual Studio 2013 à 2015 et je rencontre maintenant des problèmes avec les points d'arrêt.

C'est un succès ou un échec où les points d'arrêt fonctionneront réellement et si j'en définis un pendant le débogage, j'obtiens l'erreur:

Le point d'arrêt n'a pas pu se lier.

Toute aide serait appréciée. Je suis sur le point d'abandonner 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 vers VS 2015 Update 1 et que le problème est toujours là.

Dans l'édition précédente de VS, le démarrage du débogage déclenchait automatiquement une construction en mode débogage. Mais avec VS2015, ce n'est pas le cas.

Donc, si votre dernière version était en mode version et que vous essayez de déboguer, le point d'arrêt ne fonctionnera pas.

Vous devez d'abord créer manuellement en mode débogage, puis démarrer 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 Construction des propriétés du projet.

Cela peut sembler anodin, mais après beaucoup de problèmes avec les mêmes problèmes que vous avez mentionnés, j'ai découvert que ma version était définie sur "release" au lieu de "debug" quand j'ai essayé le débogage .. reconstruction de la solution pour "debug "l'a corrigé, et j'ai pu définir des points d'arrêt comme d'habitude

J'ai eu un problème similaire avec l'échec de la liaison des points d'arrêt, ainsi que certaines variables locales qui ne sont pas évaluées dans la fenêtre Locals. Ce qui a finalement résolu le problème, c'est 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 des performances qui a modifié le Web.configfichier avec les paramètres du moniteur de performances:

<appSettings>
   <add key="Microsoft.VisualStudio.Enterprise.AspNetHelper.VsInstrLocation" value="C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Team Tools\Performance Tools\vsinstr.exe"/>
</appSettings>


<compilation debug="true" targetFramework="4.5" 
      assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
   ...
</compilation>


<runtime>
   <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
         <assemblyIdentity name="Microsoft.VisualStudio.Enterprise.AspNetHelper" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
         <codeBase version="16.0.0.0" href="file:///D:/Program%20Files%20(x86)/Microsoft%20Visual%20Studio/Shared/Common/VSPerfCollectionTools/vs2019/Microsoft.VisualStudio.Enterprise.AspNetHelper.DLL"/>
      </dependentAssembly>
      <dependentAssembly>
         <assemblyIdentity name="VsWebSite.Interop" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
         <codeBase version="8.0.0.0" href="file:///D:/Program%20Files%20(x86)/Microsoft%20Visual%20Studio/Shared/Common/VSPerfCollectionTools/vs2019/VsWebSite.Interop.DLL"/>
      </dependentAssembly>
   </assemblyBinding>
</runtime>

Cela a brisé ma capacité à m'arrêter aux points d'arrêt. Lorsque je suis revenu au Web.config d'origine (supprimé les paramètres de Performance Profiler), les points d'arrêt ont recommencé à fonctionner.

J'ai eu le même problème hier. J'ai utilisé la fonction "Clean Solution" et cela m'a aidé.

la solution est de désactiver l'optimisation de la conception.

Project Properties> Build> Advanced Compile Options> Enable Optimizations

J'exécute des performances sur ma solution et cela a ajouté ceci à 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"/> 

l' assemblyPostProcessorTypeest le problème, je l' ai effacé et qui a résolu mon problème

Changez le mode Release en Debug, dans mon cas, cela a résolu mon problème.

Je n'ai pas modifié le paramètre «optimiser», mais sur la base d'autres réponses ici, je

1. Configurer l'Explorateur de solutions pour afficher tous les fichiers du projet
2. Suppression du bac caché et des dossiers de débogage
3. Effectuer un «nettoyage» sur le projet
4. Réaliser une «reconstruction» 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 gêné certaines choses sur mon système.

Je sais que c'est un ancien article, mais au cas où toutes les autres astuces ci-dessus ne fonctionnent pas pour vous, assurez-vous que l'image que vous essayez de déboguer est à jour. Pour une raison quelconque, après la publication et le transfert d'un projet .NET Core sur mon Raspberry Pi, «décompresser» sur le RPi ne copiait pas et n'écrasait pas certaines DLL dans le répertoire de travail. Quand j'ai attaché le débogueur en pensant que tout allait bien, certains points d'arrêt étaient touchés, d'autres pas et d'autres me donnaient l'erreur «impossible de lier». Une fois que j'ai résolu le problème de décompression, tous mes points d'arrêt et symboles sont revenus. J'espère que ça aide.

J'ai rencontré les erreurs de point 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 en faisant ci-dessous.

1. Projet propre
2. 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)
3. Reconstruire

Peut-être que cette solution aide quelqu'un.

Les points d'arrêt VS ne peuvent pas se lier aux méthodes asynchrones.

J'ai installé un agent App Dynamics qui a causé cela. Supprimez cela et vous êtes prêt à partir.

J'ai eu le même problème, mais je n'avais pas réalisé que "Debug" avait changé en "Release" dans la barre d'outils de débogage (généralement directement sous le menu). Donc je l'ai mis sur "Debug", cela a fonctionné.

La nouvelle mise à jour pour Microsoft Visual Studio 2015 Update 3 (KB3165756) a résolu le problème de point d'arrêt pour moi lorsque j'essaie d'inspecter les variables locales dans le code C # incorporé dans des fichiers cshtml dans les applications ASP.NET Core.

ÉTAPE 1, excluez l'évidence:

• Compilez en mode débogage.
• Essayez de nettoyer la solution avant de définir le point d'arrêt.
• Accédez au dossier Debug et supprimez le fichier [Votre application] .pdb.
• Ensuite, effectuez une génération ou une reconstruction de votre application.
• Accédez au dossier Debug et confirmez que vous disposez d'un tout nouveau fichier [Votre application] .pdb.
• Essayez ensuite de définir votre point de rupture.

ÉTAPE 2 Pour les projets C ++:

Vérifiez les propriétés de projet suivantes:

• C ++ / Général / Format des informations de débogage: base de données du programme.
• C ++ / Optimisation: désactivé.
• C ++ / Génération de code / Bibliothèque d'exécution: débogage multi-thread.
• Éditeur de liens / débogage / générer des informations de débogage: Oui.
• Linker / Debugging / Generate la base de données du programme: $ (TargetDir) $ (TargetName) .pdb.
• Éditeur de liens / fichier manifeste / générer un manifeste: Non.
• Éditeur de liens / fichier manifeste / autoriser l'isolement: Non.
• Éditeur de liens / IDL intégré / Ignorer l'IDL intégré: Oui.

• Refaites l'étape 1

  Vous pouvez essayer d'ajouter __debugbreak (). Cette instruction doit aller dans votre fichier source où vous souhaitez interrompre.

ÉTAPE 2 Pour les projets C #:

• Dans les propriétés du projet, le code Build / General / Optimize doit être désactivé.
• Dans les paramètres IDE Débogage / Options et paramètres / Débogage / Général Suppression de l'optimisation JIT lors du chargement du module (géré uniquement): Activé
• Refaites l'étape 1

Essayez d'ouvrir votre solution sur une autre machine. 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:

Des problèmes comme celui-ci ont été signalés dans le VS2013 RTM ainsi que dans VS2015 Update 1 et Update2.

Dans VS, accédez à Outils / Extensions et mises à jour / Mises à jour / Mises à jour de produit et voyez quelle version vous utilisez. Si une mise à jour est nécessaire, elle y apparaîtra.

ÉTAPE 4, assurez-vous que votre système d'exploitation est à jour:

Enfin, si vous exécutez un système d'exploitation Win 10, un bogue concernant ce problème existait dans la version 14251. Cela a été résolu dans la version 14257 (et supérieure).

Je viens de rencontrer un problème similaire et aucune des réponses ici ne correspond au problème auquel je suis confronté. Contrairement à la question, cependant, je ne reçois jamais de message disant qu'il y a eu un échec de liaison. Le point d'arrêt ne frappe jamais. J'espère que cela sera utile à quelqu'un à l'avenir se cogner la tête contre le mur avec la WCF.

TL / DR:
Dans le message SOAP, il y avait un enregistrement avec des données incorrectes qui empêchait le point d'arrêt d'être atteint.

Histoire complète:

J'ai un service WCF basé sur WSDL d'une autre équipe. Pas ma définition, pas de contrôle dessus ... Je reçois des messages de cette autre équipe via ce service. Dans mon cas, je reçois des messages, je peux enregistrer le message dans la table du journal des messages dans la base de données (ce qui se produit avant que ma méthode de service ne soit appelée), la méthode de service est apparemment appelée (peut-être que ce n'est pas le cas) et le serveur répond par 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 méthode.

Étant donné que le service renvoie une réponse réussie, 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. J'ai mis un point d'arrêt sur la première ligne de la méthode de service et envoyé le gros message, mais le point d'arrêt n'a jamais atteint. J'ai essayé un message plus petit dont je savais qu'il fonctionnait sur la même instance d'exécution et le point d'arrêt a été atteint très bien. Donc, tout dans la configuration semblait bien. J'ai pensé qu'il y avait peut-être quelque chose dans la taille du message.

J'ai essayé tout ce que je pouvais trouver - m'assurer que j'étais dans une configuration de débogage, nettoyer et reconstruire, attacher manuellement le débogueur au processus w3wp (ce que VS était déjà), en utilisant Debugger.Break()au lieu d'un point d'arrêt, en définissant plusieurs projets de démarrage, en déchargeant mon projet de test afin que le projet de service soit le seul, mettre à jour .NET, redémarrer VS2015, redémarrer, passer d'IIS local à IIS Express et inversement, recréer le service avec le dernier WSDL garanti. Rien n'avait d'importance. Le point d'arrêt n'a jamais été atteint.

J'ai fini par avoir à éliminer les enregistrements du gros message un par un jusqu'à ce que je trouve un seul enregistrement contenant des données incorrectes. Dans mon cas, c'était un enregistrement qui n'avait aucune valeur pour 2 champs DateHeure. Lorsque j'ai créé un message contenant uniquement cet enregistrement et que je l'ai envoyé, le point d'arrêt n'a pas été atteint. Lorsque 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.

J'avais toutes les exceptions CLR activées, rien d'autre que des fichiers .pbd manquants, dont je ne me souciais pas. WCF a volontiers envoyé la demande avec un mauvais enregistrement. Je ne dis pas que WCF n'aurait pas dû l'envoyer en fonction des contrats, mais simplement que le mauvais bilan a empêché le point d'arrêt d'être atteint.

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

Nettoyez toute la solution avant d'essayer l'une des autres solutions. Après avoir essayé presque tout le reste des réponses précédentes et redémarré plusieurs fois Visual Studio, il suffit de nettoyer la solution!

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, la page et le paramètre de requête. Fait un nettoyage et une reconstruction en mode débogage et cela a atteint mon point d'arrêt.

Bien qu'il s'agisse d'une version beaucoup plus récente (VS2017), j'ai eu ce problème avec les projets C #. Essayé de nettoyage, de reconstruction, de redémarrage de Visual Studio, etc.

Ce qui a corrigé, c'était la fermeture de Visual Studio et la suppression du dossier .vs, qui est un dossier caché situé dans le répertoire de la solution. La suppression du dossier .vs ne devrait pas vous poser de problèmes, même si vous devrez réinitialiser votre projet de démarrage.

Dans mon cas, il y avait un nouveau fichier web.config créé après mon utilisation Profiler. La restauration de web.config vers la version précédente a résolu ce problème. C'était une application Web VS2015 C #.

Si vous publiez votre application Web, vérifiez qu'il Configurationest défini sur Debug(par défaut, dans la configuration de débogage, il est défini de telle sorte que le code non est optimisé et que la table des symboles est entièrement créée).

J'ai regardé les réponses précédentes et les answear de @ Will ont résolu le problème principal que j'avais, l'autre étant capable de modifier et de continuer, mais en examinant de plus près le fichier AssemblyInfo.cs, j'ai découvert certaines fonctionnalités de débogage désactivées.

Ensuite, j'ai fini par supprimer les anciens attributs de débogage et ajouter ce qui suit que j'ai pris d'un autre projet

#if DEBUG
[assembly: System.Diagnostics.Debuggable(System.Diagnostics.DebuggableAttribute.DebuggingModes.DisableOptimizations | System.Diagnostics.DebuggableAttribute.DebuggingModes.EnableEditAndContinue | System.Diagnostics.DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | System.Diagnostics.DebuggableAttribute.DebuggingModes.Default)]
#endif

Pourtant, je pense que ce n'est pas la meilleure façon de le faire.