Le projet VS2015 ne s’exécute plus en mode débogage

C’est ce que j’obtiens même lorsque je cours dans la configuration Debug.

La façon dont je l’ai eu à montrer était en activant “Just My Code” et Warn si aucun code utilisateur lors du lancement. C’est quelque chose qui est récemment arrivé à notre projet et je ne suis pas sûr de ce que nous avons fait pour provoquer cela. Mais j’ai été incapable de le réparer. Les points de rupture ne se déclenchent pas et une surveillance rapide donne des résultats étranges.

J’ai essayé de googler le problème mais aucune des solutions standard n’a fonctionné. Je suis tout en dehors des idées.

Mise à jour : J’ai vérifié le gestionnaire de configuration et chaque projet est également défini sur Debug. entrer la description de l'image ici

Mise à jour 2 : J’ai désactivé “Activer les optimisations” et je n’obtiens plus la boîte de dialog “Vous êtes en train de déboguer une version Release”. Il fonctionne et s’arrête à nouveau sur les points d’arrêt! Cependant, la fenêtre de sortie affiche ceci au démarrage:

Les symboles du module ‘Navigo.exe’ n’ont pas été chargés.

  1. Utilisez une configuration de construction de débogage ou désactivez l’option de débogage «Activer Just My Code».
  2. Vérifiez les parameters des symboles sous les options de débogage.

Cela résout donc mon problème principal de ne plus pouvoir utiliser les points d’arrêt et la fenêtre contextuelle. Ce qui est étrange puisque je pensais que vous deviez charger des symboles pour que les points d’arrêt fonctionnent. Alors, comment les points d’arrêt peuvent-ils fonctionner si les symboles ne sont pas chargés? Peut-être que c’est juste un mauvais message?

Utilisez le gestionnaire de configuration pour vérifier les parameters réels de la configuration de débogage – il s’agit de Build \ Configuration Manager dans le menu principal – au cas où ils sont configurés pour utiliser Release:

Panneau de configuration

Assurez-vous également que le projet définit correctement DEBUG et que l’option “Optimiser le code” n’est pas cochée:

Propriétés

Cela m’est arrivé sur quelques projets aussi. J’ai examiné mes parameters de construction, comme suggéré par stuartd . Toutefois, l’option «Optimiser le code» n’était pas activée dans mes parameters de génération. Je l’ai donc activé et enregistré le projet. Ensuite, j’ai décoché et enregistré à nouveau. Problème résolu.

Il y a une sorte de bogue qui fait --optimize+ drapeau --optimize+ au débogueur. L’activer puis le désactiver est une solution simple jusqu’à ce que le bogue soit résolu.

Je veux juste intervenir et dire que cela a commencé à m’arriver après l’application de la mise à jour 1. Les projets existants ont commencé à le montrer et je peux le reproduire avec un tout nouveau projet. Toutes les configurations sont définies sur DEBUG, Optimiser n’est pas coché. Le kicker est que l’exécution du projet pour la première fois (ou après un nettoyage) fonctionne correctement, sans aucun message. Arrêter, puis relancer le projet (remarque – le projet N’EST PAS REBUILT) affichera la boîte de dialog. La seule solution consiste à désactiver l’option Just My Code, qui semble être un hack, comme c’était le cas avant la mise à jour 1 sans aucun problème.

Si aucune des solutions mentionnées ne vous a aidé, vérifiez le fichier AssemblyInfo.cs de votre projet pour une application explicite DebuggableAtsortingbute. On dirait qu’il remplace les options de débogage / de libération du compilateur.

Avait cette ligne dans le fichier dans mon cas (projet hérité, aucune idée de la façon dont il est arrivé là). Sa suppression a résolu le problème:

 [assembly: System.Diagnostics.Debuggable(System.Diagnostics.DebuggableAtsortingbute.DebuggingModes.IgnoreSymbolStoreSequencePoints)] 

Un peu tard pour la fête mais j’ai aussi rencontré ce problème. Le correctif qui a fonctionné était de nettoyer et de reconstruire mes projets.

Sélectionnez Déboguer> Options et désélectionnez l’ Suppress JIT optimization . Ça marche pour moi.

Source: https://connect.microsoft.com/VisualStudio/feedback/details/2116788/flag-optimize-is-passed-to-the-debugger-even-while-the-build-settings-optimize-code-is- non-activé-sur-mvc-c-web-projects-quand-just-my-code

Aucune des réponses ci-dessus n’a fonctionné pour moi. Le redémarrage d’IIS a résolu le problème.

Il suffit d’append une note à la réponse de stuartd:

Assurez-vous de vérifier les projets dépendants pour les mêmes parameters de construction. Vous obtiendrez le même message si votre projet principal possède les parameters appropriés, mais pas vos projets dépendants. Cela a un sens évident dans la vue arrière, mais ce n’était pas la première chose à laquelle je pensais.

Appréciez le fait que ce soit un ancien message, mais c’est le premier qui est apparu sur Google alors que je cherchais la réponse, donc il est probable que d’autres viendront aussi.

Dans mon cas, le problème était que l’URL du projet IIS dans l’onglet Web des propriétés du projet ASP.NET était définie sur une URL incorrecte. Il indiquait http: // localhost que j’utilisais avec une copie différente du projet. L’adresse de la solution que j’avais ouverte était en fait configurée sur mon serveur IIS local sous la forme http: // localhost: 90 .

Passer à la bonne adresse a résolu le problème.

entrer la description de l'image ici

J’ai eu le même problème … Quoi que je fasse, rien n’a fonctionné. C’était un nouveau projet vide qui était le problème. J’ai fini par retirer le projet et ajouté un nouveau projet – le nouveau projet devait avoir un autre nom ; Si j’utilisais le même nom, l’erreur réapparaissait – même après un redémarrage, nettoyez et reconstruisez … Ce doit être un bogue dans VS 2015.

Pour moi, c’était une référence Nuget à partir d’un serveur Nuget privé. Je ne sais pas comment cela a été compilé, mais changer la référence à une référence de projet m’a permis de surmonter le problème.

J’ai essayé à peu près tout dans cette liste, mais à la fin j’ai résolu ce problème en ouvrant les propriétés de la solution et en passant de “Plusieurs projets de démarrage” à “Projet de démarrage unique” et inversement.

  1. Faites un clic droit sur la solution et choisissez “Propriétés”
  2. Sous “Propriétés communes”, modifiez la sélection “Plusieurs projets de démarrage” en “Projet de démarrage unique”
  3. Cliquez sur OK
  4. Exécuter le débogage
  5. Terminez le débogage et répétez les étapes 1 à 3, mais revenez à “Plusieurs projets de démarrage”
  6. Exécuter à nouveau le débogage avec plusieurs projets

J’ai ouvert mon projet VS2012Pro dans VS2015Express et j’ai eu le même problème.

J’ai vérifié mes propriétés de solution | Propriétés de configuration et découvert qu’un projet était défini sur Release & x86.

Je suis revenu à Debug & Any CPU, et l’invite a disparu.

Dans mon cas, je développais un plug-in VSTO pour Outlook et Outlook chargeait accidentellement la version Release de la DLL que j’ai récemment installée lors du test de mon programme d’installation. Il semble que VS essayait d’utiliser cette DLL au lieu de celle de Debug que j’attendais. La correction de la DLL chargée par Outlook a résolu ce problème pour moi.

J’ai rencontré le problème, finalement je l’ai résolu en choisissant “Désactiver juste mon code et continuer”.

Juste mon code

Étapes de résolution:

Accédez aux parameters de création du projet incriminé.

Faites défiler jusqu’au bouton «Avancé».

Assurez-vous que «Informations de débogage» n’est PAS défini sur «Aucun».

Je vous recommande d’utiliser l’option complète.

Heureux de t’aider

Après avoir visualisé le lien par Pasortingck en tant que commentaire à la question , quelqu’un a noté une solution de contournement consistant à arrêter le site dans IIS Express. J’ai été en mesure d’empêcher ce même problème en faisant juste cela après avoir arrêté le débogueur dans Visual Studio. Cependant, je m’intéressais davantage à la question et je pense que cela pourrait également être lié au paramètre «Modifier et continuer» du débogueur. Lorsque j’ai désactivé cela dans les options de Visual Studio, je n’avais plus le problème. Mais cela vous empêcherait d’utiliser la fonctionnalité Modifier et continuer. Vous ne savez donc pas si cela en vaut la peine.

Outils> Options> Débogueur> Modifier et continuer (défiler vers le bas de la liste Général)> Décochez la case Modifier et continuer.

Je l’ai également ressenti soudainement après l’installation de la mise à jour 1, mais il se peut que j’aie eu cette mise au point en premier lieu.

Copier mon autre réponse d’ ici .

Comme mentionné par @romanoza, Microsoft a mis à jour le rapport de bogue avec les informations suivantes:

Décochez le paramètre Debug -> Options -> Supprimer l’optimisation JIT sur la charge du module (Géré uniquement)

C’est la solution de contournement. Ils continuent à dire plus tard:

Nous recommandons aux gens de ne pas les contrôler car leur décochage améliorera à la fois les performances et le comportement de mon code dans des scénarios spécifiques.

Enfin, la reconnaissance:

C’est un bogue qui ne fonctionne pas avec ce paramètre activé et nous travaillons sur un correctif pour cette situation dans le cas où certains clients veulent toujours déboguer avec ce paramètre activé.

… au cas où il vous suffirait de continuer sans plus tarder, sélectionnez la dernière option de la fenêtre contextuelle et tout se passera comme avant.

entrer la description de l'image ici

C’était une alerte étrange.

La reconstruction de la solution ne supprime pas nécessairement toutes les DLL (en particulier celles copiées à partir de projets dépendants).

Cependant, la reconstruction du projet de dépendance a fait disparaître cette alerte.

Face à cela avec VS2015 Update 3.

Ma solution était un peu différente de toutes les autres et est un peu unique.

Je travaille avec un site Web qui contient un mélange de code managé et d’ASP classique, les deux faisant référence au même assemblage. Visual Studio se plaignait que ma DLL gérée était une version finale.

Le problème était une exception non capturée dans mon assembly, mais il était lancé par une page ASP classique via interop. Visual Studio n’a pas pu gérer ce problème et a affiché le message d’erreur. La même exception émise à partir du code managé aurait amené le débogueur comme prévu.

Corriger le problème dans le constructeur de mon assembly géré a tout corrigé.

Cela fait du sens maintenant que je repense à la situation dans son ensemble, mais à l’époque, le message d’erreur m’avait plongé dans une voie très profonde et j’ai tout essayé jusqu’à ce que j’aie eu “Ah-ha!” moment.

J’ai passé 2 jours et il semble que Reset the Visual Studio 2017 Experimental Instance m’a aidé.