VS 2015 Update 1 - Réclamer que je débogue une version de version

Après la mise à jour vers la mise à jour 1 de VS 2015, si j'exécute un projet Web (MVC), arrêtez l'application, puis essayez de l'exécuter à nouveau, VS s'arrête et fait apparaître une boîte de dialogue réclamant

Vous déboguez une version Release de <myproject.dll>.

L'utilisation de Just My Code avec des versions de version utilisant les optimisations du compilateur entraîne une expérience de débogage dégradée (par exemple, les points d'arrêt ne seront pas atteints).

Le problème est que je n'exécute pas une version de version. J'exécute clairement la (même) version de débogage que je viens de lancer! Pourquoi VS pense-t-il que j'exécute une version de version?

Le nettoyage de la solution et la réexécution efface le message d'erreur, donc quelque chose est arrosé quelque part.

Le mot de Microsoft est qu'il s'agit d'un problème connu (à l'origine, il est allé à l'équipe de débogage, mais il a été déterminé qu'il s'agissait d'un problème de construction, et est maintenant entre les mains de l'équipe du système de projet. Il y a d'autres bogues ouverts sur ce problème, et c'est classé Priorité 1, devrait donc être sur la bonne voie pour la prochaine mise à jour. Bien que, comme on pouvait s'y attendre, aucune promesse ne puisse être faite quant à la date de sa sortie (ou à ce qui est réellement dans la mise à jour).

Alors. Il est connu et est en cours d'élaboration. Au moins, désactiver l'option «Activer uniquement mon code» dans les options générales de débogage semble être une solution pour le moment.

Comme mentionné par @romanoza, Microsoft a mis à jour le rapport de bogue (maintenant manquant) de Microsoft Connect, (précédemment situé ici , au cas où vous pourriez trouver une archive quelque part) avec les informations suivantes:

Décochez le paramètre Déboguer -> Options -> Supprimer l'optimisation JIT lors du chargement du module (géré uniquement)

C'est la solution de contournement. Ils continuent en disant plus tard:

Nous recommandons aux gens de ne pas cocher cette case, car elle améliorera à la fois les performances et le comportement de mon code uniquement dans des scénarios spécifiques.

Enfin, la reconnaissance:

C'est un bogue que cela ne fonctionne pas avec ce paramètre activé et nous travaillons sur un correctif pour cette situation au cas où certains clients voudraient toujours déboguer avec ce paramètre activé.

Mise à jour : Sur la base des commentaires, il semble que la case soit désormais désactivée par défaut pour certains développeurs, et que sa vérification peut résoudre exactement le même problème dans certains cas. Très étrange.

J'ai remarqué que les réponses ici sont incomplètes, j'avais le même problème et il a été résolu en ouvrant les propriétés du projet et sous l'onglet de construction et de configuration de débogage en décochant «optimiser le code» . Vous devriez également vérifier le gestionnaire de configuration comme mentionné ci-dessus pour vous assurer que c'est également le son. La réponse est venue de cet article et ils devraient obtenir le crédit: VS2015 Project ne fonctionne plus en mode débogage

Merci,

J'ai résolu le problème en définissant la configuration sur Debug dans la fenêtre Configuration Manager , comme suggéré dans cette réponse .

Le nettoyage (et la reconstruction) de la solution fonctionne pour moi comme une solution de contournement temporaire. Vous pouvez également sélectionner Déboguer> Options et décocher la Suppress JIT optimizationcase.

J'ai eu le même problème depuis la mise à jour vers VS2015 Update 1.

J'ai trouvé un rapport similaire sur les forums Visual Studio de Microsoft qui pointe vers un rapport de bogue qui a été soulevé avec eux ici

Il existe différentes solutions de contournement, mais je pense que le problème sous-jacent est que IIS Express ne s'arrête pas lorsque le débogage est terminé - et ce n'est pas à cause de la décocher de l'option Modifier et continuer. Solution de contournement la plus rapide que je puisse trouver jusqu'à ce que le bogue soit corrigé:

• Faites un clic droit sur l'icône IIS Express dans la barre d'état et quittez-la après le débogage (crédit à David Totzke qui a fourni une solution de contournement sur le rapport de bogue)

Pas génial, mais je ne pense pas qu'une solution appropriée soit disponible pour le moment.

J'ai rencontré le même problème. J'ai résolu le problème en supprimant manuellement tous les fichiers du dossier «bin», puis en reconstruisant la solution. Je n'ai plus ce dialogue.

Dans mon cas, j'avais changé la "plate-forme de solution active" pour toute la solution dans "Configuration Manager" de x86 à N'importe quel processeur, corrigé le problème

Vérifiez les propriétés de configuration de votre solution. J'ai rencontré le même problème et j'ai découvert que ma configuration de débogage construisait en fait des projets avec une configuration de version.

J'ai remarqué que Visual Studio ne tuait pas le processus iisexpress après avoir arrêté le débogueur. Tuer manuellement le processus a semblé résoudre le problème pour moi.

Cela semble avoir été corrigé dans la mise à jour 2.

Il semble y avoir autant de solutions que de personnes ayant le problème, mais dans mon cas, j'ai dû supprimer et rajouter une référence de projet. La référence du projet se trouvait dans un projet de test unitaire dans la même solution.

Dans mon cas, le message d'erreur était correct. J'exécutais une application qui chargeait la version publiée. Je l'ai donc corrigé en demandant à l'application de charger la version de débogage à la place.

Élémentaire, je sais, et je me rends compte que je me fais passer pour un idiot. Mais parfois, le problème est exactement ce qui est signalé.

Vérifiez que l'URL du projet IIS pointe réellement là où vous pensez. En cas de doute, cliquez sur le bouton «Créer un répertoire virtuel».

J'ai eu ce problème récemment où j'avais exécuté une version temporaire d'une base de code de production et j'avais repointé le dossier dans IIS vers la version temporaire, qui était, en fait, exécutant une version de production, pas la version de débogage que j'essayais de déboguer.

Pour moi, j'ai trouvé 3 références de dossier \ Release \ dans ce fichier FileListAbsolute.txt:

C: \ Projects \ MyWebApp.Web \ obj \ Release \ MyChildWebApp.Web.csproj.FileListAbsolute.txt

Ils étaient comme ça:

C: \ Projects \ MyWebApp.Web \ obj \ Release \ MyChildWebApp.Web.csprojResolveAssemblyReference.cache

C: \ Projects \ MyWebApp.Web \ obj \ Release \ MyChildWebApp.Web.dll

C: \ Projects \ MyWebApp.Web \ obj \ Release \ MyChildWebApp.Web.pdb

Et simplement supprimer ces 3 lignes en dehors de VS, puis rouvrir la solution a résolu le problème. J'espère que cela pourra aider.

J'ai essayé toutes les réponses, et celle qui a fonctionné pour moi est de supprimer un package NuGet, pas seulement la référence, mais de supprimer le package, dans mon cas PostSharp. Au début, j'ai essayé de supprimer la référence de tous les projets, et cela ne fonctionne pas, puis j'ai simplement supprimé les packages du gestionnaire. Je ne sais pas exactement la raison, mais c'est ce qui a résolu mes problèmes, j'espère que cela pourrait aider quelqu'un là-bas.

Redémarrez Visual Studio. Cela a résolu le problème pour moi dans 2017 Professional.

Voici ce qui a fonctionné pour moi.

S'il s'agit d'un projet Web, accédez aux propriétés du projet du projet Web et

1. Si IIS local est sélectionné, redémarrez votre serveur IIS.
2. Si IIS Express est sélectionné, quittez IIS Express à partir de l'icône de la barre des tâches.

Il semble que certaines dll soient mises en cache, donc les étapes ci-dessus invalideront le cache.

Cela s'est produit dans Visual Studio 2019 sur une application UWP. La non-vérification du code d’optimisation dans les paramètres de csproj / build a résolu le problème.

À peu près sûr que cela a été corrigé dans Visual Studio 2015 Update 2.

J'avais l'habitude de voir cela tout le temps (plusieurs fois par jour) et je ne l'ai pas vu une seule fois depuis la mise à jour vers la mise à jour 2.