VS 2015 Update 1 - Ich behaupte, ich debugge einen Release-Build

Wenn ich nach dem Update auf VS 2015 Update 1 ein Webprojekt (MVC) ausführe, die Anwendung stoppe und dann erneut versuche, stoppt VS und öffnet einen Dialog, in dem behauptet wird

Sie debuggen einen Release-Build von <myproject.dll>.

Die Verwendung von Just My Code mit Release-Builds unter Verwendung von Compiler-Optimierungen führt zu einer verschlechterten Debugging-Erfahrung (z. B. werden Haltepunkte nicht erreicht).

Das Problem ist, dass ich keinen Release-Build ausführe. Ich verwende eindeutig den (gleichen) Debug-Build, den ich gerade ausgeführt habe! Warum glaubt VS, dass ich einen Release-Build ausführe?

Durch Reinigen der Lösung und erneutes Ausführen wird die Fehlermeldung gelöscht, sodass irgendwo etwas abgespritzt wird.

Das Wort von Microsoft besagt, dass dies ein bekanntes Problem ist (es ging ursprünglich an das Debugger-Team, wurde jedoch als Build-Problem eingestuft und liegt nun in den Händen des Project-Systemteams. Es sind weitere Fehler zu diesem Problem offen, und es ist bewertet Priorität 1, sollte also für das nächste Update auf dem richtigen Weg sein. Obwohl zu erwarten, können keine Zusagen gemacht werden, wann es veröffentlicht wird (oder was tatsächlich im Update enthalten ist).

So. Es ist bekannt und wird bearbeitet. Zumindest das Deaktivieren von "Nur meinen Code aktivieren" in den allgemeinen Debugging-Optionen scheint vorerst eine Problemumgehung zu sein.

Wie von @romanoza erwähnt, hat Microsoft den (jetzt fehlenden) Microsoft Connect-Fehlerbericht (der sich zuvor hier befand , falls Sie irgendwo ein Archiv finden können) mit den folgenden Informationen aktualisiert :

Deaktivieren Sie die Einstellung Debug -> Optionen -> JIT-Optimierung beim Laden des Moduls unterdrücken (nur verwaltet).

Dies ist die Problemumgehung. Sie sagen später weiter:

Wir empfehlen Leuten, die es nicht aktivieren, da das Deaktivieren sowohl die Leistung als auch das Verhalten nur meines Codes in bestimmten Szenarien verbessert.

Zuletzt die Bestätigung:

Es ist ein Fehler, dass es mit dieser aktivierten Einstellung nicht funktioniert, und wir arbeiten an einer Lösung für diese Situation, falls einige Kunden weiterhin mit dieser aktivierten Einstellung debuggen möchten.

Update : Auf der Grundlage der Kommentare scheint es , dass die Box nun un standardmäßig markiert für einige Entwickler, und dass die Überprüfung kann es genau das gleiche Problem in einigen Fällen beheben. Sehr eigenartig.

Ich habe festgestellt, dass die Antworten hier unvollständig sind, ich hatte das gleiche Problem und es wurde gelöst, indem die Projekteigenschaften geöffnet und unter der Registerkarte " Erstellen" und Debug-Konfiguration das Kontrollkästchen "Code optimieren" deaktiviert wurden . Sie sollten auch den Konfigurationsmanager wie oben erwähnt überprüfen, um sicherzustellen, dass er auch einwandfrei ist. Die Antwort kam von diesem Beitrag und sie sollten die Gutschrift erhalten: VS2015 Project wird nicht mehr im Debug-Modus ausgeführt

Vielen Dank,

Ich löste das Problem , das die Konfiguration der Einstellung Debug in den Configuration Manager - Fenstern , wie in dieser vorgeschlagenen Antwort .

Das Reinigen (und Wiederherstellen) der Lösung funktioniert für mich als vorübergehende Problemumgehung. Sie können auch Debug> Optionen auswählen und das Suppress JIT optimizationKontrollkästchen deaktivieren.

Ich habe das gleiche Problem seit dem Update auf VS2015 Update 1.

In den Visual Studio-Foren von Microsoft wurde ein ähnlicher Bericht gefunden, der auf einen Fehlerbericht verweist, der mit ihnen erstellt wurde wurde

Es gibt verschiedene Problemumgehungen, aber ich denke, das zugrunde liegende Problem ist, dass IIS Express nicht beendet wird, wenn das Debuggen beendet wird - und dies nicht, weil die Option zum Bearbeiten und Fortfahren deaktiviert ist. Schnellste Problemumgehung, die ich finden kann, bis der Fehler behoben ist:

• Klicken Sie mit der rechten Maustaste auf das IIS Express-Symbol in der Taskleiste und beenden Sie es nach dem Debuggen (Dank an David Totzke, der die Problemumgehung für den Fehlerbericht bereitgestellt hat).

Nicht großartig, aber ich denke, dass im Moment keine richtige Lösung verfügbar ist.

Ich bin auf das gleiche Problem gestoßen. Ich habe das Problem behoben, indem ich alle Dateien manuell aus dem Ordner 'bin' gelöscht und dann die Lösung neu erstellt habe. Ich verstehe diesen Dialog nicht mehr.

In meinem Fall hatte ich die "Active Solution Platform" für die gesamte Lösung in "Configuration Manager" von x86 auf "Any CPU" geändert und das Problem behoben

Überprüfen Sie die Konfigurationseigenschaften Ihrer Lösung. Ich bin auf dasselbe Problem gestoßen und habe festgestellt, dass meine Debug-Konfiguration tatsächlich einige Projekte mit einer Release-Konfiguration erstellt.

Ich habe festgestellt, dass Visual Studio den iisexpress-Prozess nicht beendet hat, nachdem ich den Debugger gestoppt habe. Das manuelle Beenden des Prozesses schien es für mich zu beheben.

Dies scheint nun in Update 2 behoben worden zu sein.

Es scheint so viele Lösungen zu geben, wie es Menschen gibt, die das Problem haben, aber in meinem Fall musste ich eine Projektreferenz entfernen und erneut hinzufügen. Die Projektreferenz befand sich in einem Unit-Test-Projekt in derselben Lösung.

In meinem Fall war die Fehlermeldung korrekt. Ich habe eine Anwendung ausgeführt, die die veröffentlichte Version geladen hat. Also habe ich es korrigiert, indem die Anwendung stattdessen die Debug-Version geladen hat.

Elementar, ich weiß, und mir ist klar, dass ich mich wie ein Idiot aussehe. Aber manchmal ist das Problem genau das, was gemeldet wird.

Überprüfen Sie, ob die IIS-Projekt-URL tatsächlich zeigt, wo Sie glauben, dass dies der Fall ist. Klicken Sie im Zweifelsfall auf die Schaltfläche "Virtuelles Verzeichnis erstellen".

Ich hatte kürzlich dieses Problem, bei dem ich eine temporäre Version einer Produktionscodebasis ausgeführt und den Ordner in IIS auf die temporäre Version umgestellt hatte, in der tatsächlich ein Produktionsbuild ausgeführt wurde, nicht die Debug-Version, die ich zu debuggen versuchte.

Für mich habe ich 3 \ Release \ Ordnerreferenzen in dieser FileListAbsolute.txt-Datei gefunden:

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

Sie waren so:

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

Durch einfaches Entfernen dieser drei Zeilen außerhalb von VS und erneutes Öffnen der Lösung wurde das Problem behoben. Hoffentlich hilft das.

Ich habe alle Antworten ausprobiert, und die für mich funktionierende ist, ein NuGet-Paket zu entfernen, nicht nur die Referenz, sondern das Paket, in meinem Fall PostSharp. Zuerst habe ich versucht, die Referenz aus allen Projekten zu entfernen, und es funktioniert nicht. Dann habe ich einfach die Pakete aus dem Manager entfernt. Ich weiß nicht genau, warum, aber das hat meine Probleme gelöst. Ich hoffe, es könnte jemandem da draußen helfen.

Starten Sie Visual Studio neu. Dies hat das Problem für mich in 2017 Professional behoben.

Hier ist, was für mich funktioniert hat.

Wenn es sich um ein Webprojekt handelt, gehen Sie zu den Projekteigenschaften des Webprojekts und

1. Wenn Lokaler IIS ausgewählt ist, starten Sie Ihren IIS-Server neu.
2. Wenn IIS Express ausgewählt ist, beenden Sie IIS Express über das Taskleistensymbol.

Es scheint, dass einige DLLs zwischengespeichert werden, sodass die obigen Schritte den Cache ungültig machen.

Dies geschah in Visual Studio 2019 in einer UWP-App. Das Deaktivieren von Optimize Code in den csproj / build-Einstellungen wurde behoben.

Ziemlich sicher, dass dies in Visual Studio 2015 Update 2 behoben wurde.

Ich habe dies die ganze Zeit (mehrmals pro Tag) gesehen und seit dem Update auf Update 2 kein einziges Mal gesehen.