"Ausdruck kann nicht ausgewertet werden, da der Code der aktuellen Methode optimiert ist" in Visual Studio 2010

Ich hatte dieses Problem, als ich VS 2010 verwendete. Meine Lösungskonfiguration (Debug) wurde ausgewählt. Ich habe das Problem gelöst, indem Sie die Eigenschaft Optimize Code unter den Projekteigenschaften deaktivieren. Projekt (Rechtsklick) => Eigenschaften => Erstellen (Registerkarte) => Deaktivieren Sie Code optimieren

Es klingt, als würden Sie einen optimierten/freigegebenen Build debuggen, obwohl das Kontrollkästchen deaktiviert ist. Dinge, die Sie ausprobieren können, sind:

• Führen Sie eine vollständige Neuerstellung Ihrer Lösungsdatei durch (klicken Sie mit der rechten Maustaste auf die Lösung und wählen Sie Alle neu erstellen).
• Öffnen Sie beim Debuggen das Modulfenster (Debug -> Windows -> Module) und suchen Sie Ihre Assembly in der Liste der geladenen Module. Vergewissern Sie sich, dass der Pfad, der in Ihrer geladenen Assembly angegeben ist, der erwartete ist, und dass der geänderte Zeitstempel der Datei anzeigt, dass die Assembly tatsächlich neu erstellt wurde.
• Das Modulfenster sollte auch anzeigen, ob das geladene Modul optimiert ist oder nicht. Vergewissern Sie sich, dass das Modulfenster anzeigt, dass es nicht optimiert ist.

Wenn Sie den Menüpunkt "Module" im Menü "Debug -> Windows" nicht sehen können, müssen Sie ihn möglicherweise im Menü "Anpassen ..." hinzufügen.

In VS2013 gehen Sie zu: Extras -> Optionen -> Debugging -> Allgemein und aktivieren Sie 'Verwalteten Kompatibilitätsmodus verwenden'. Dadurch wird das neue Funktionsbewertungsverhalten deaktiviert.

Versuchen Sie, im Debug-Modus auszuführen. Wenn Sie im Freigabemodus arbeiten, wird diese Meldung angezeigt.

Ich hatte das gleiche Problem in VS2008. In meinem Fall wurde es durch Lösungsumbau gelöst.

Meine Situation wurde durch keine der obigen Antworten abgedeckt. Ich habe folgendes gefunden: MSDN article über Threading, das erklärt, dass der Debugger nicht auf die Daten zugreifen kann, wenn er in einigen primitiven nativen Threadingoperationen stecken bleibt. Wenn beispielsweise ein Thread auf Task.Wait () sitzt, wird dies angezeigt.

Ich hatte das gleiche Problem. In meinem Fall war das Debuggable-Attribut jedoch fest in der AssemblyInfo.cs-Datei meines Projekts codiert und wurde daher nicht durch Kompilierung (über-) geschrieben. Nach dem Entfernen der Zeile mit dem Attribut Debuggable hat es funktioniert.

Abgesehen von @Kragen, wenn Sie ein Webprojekt debuggen

schließen Sie das Visual Studio und versuchen Sie, die temporären Dateien unter C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporäre ASP.NET-Dateien zu löschen

Wenn der Ausdruck " Kann nicht ausgewertet werden, da der Code der aktuellen Methode optimiert ist. " nach der Ausgabe einer Debugger.Break()-Anweisung angezeigt wird, stellen Sie sicher, dass Sie die nächste Anweisung mit F10 aufrufen.

Sobald Sie zur nächsten Anweisung übergegangen sind und vorausgesetzt, dass Sie einen Debug-Build ausführen, sollte diese Meldung verschwinden.

Ich hatte das gleiche Problem beim Debuggen einer Klassenbibliothek von einer Testbed-Web-App. Ich habe auf die Release-Version in der Testumgebung verwiesen und diese wurde in den Eigenschaften der Klassenbibliothek optimiert.

Wenn Sie das Kontrollkästchen "Optimierungscode" für die Release-Version in den Eigenschaften der Klassenbibliothek deaktivieren, während ich schreibe, wurde das Problem behoben.

Mir ist klar, dass dies eine spätere Antwort ist, aber ich fand einen weiteren Hinweis auf eine Möglichkeit, dieses Problem anzugehen, das anderen in der Zukunft helfen könnte. Diese Webseite beschreibt das Setzen einer Umgebungsvariablen (COMPLUS_ZapDisable = 1), die eine Optimierung verhindert, zumindest für mich! (Vergessen Sie nicht den zweiten Teil der Deaktivierung des Visual Studio-Hosting-Prozesses.) In meinem Fall war dies möglicherweise noch relevanter, da ich ein externes DLL über einen Symbol-Server debuggen musste, aber ich bin mir nicht sicher .

Eine andere Sache, die Sie tun können, ist, erstellen Sie eine Datei mit dem gleichen Namen wie die DLL, die optimiert ist, aber mit der Erweiterung "ini", und fügen Sie der Datei Folgendes hinzu:

[.NET Framework-Debugging-Steuerelement]
GenerateTrackingInfo = 1
AllowOptimize = 0

Dies weist die JIT an, Ihre Variablen nicht zu optimieren.

Beachten Sie, dass Sie die pdb immer noch benötigen, sodass Sie am Ende etwa Folgendes haben: IhreDll.dll IhreDll.pdb IhreDll.ini

Dies funktioniert besonders gut in Szenarien, wenn Sie nicht über die Möglichkeit verfügen, die DLLs mit Debug-Option erneut zu generieren.

http://www.hanselman.com/blog/DebugVsReleaseTheBestOfBothWorlds.aspx

In Bezug auf das Problem, dass die Eigenschaft "Code optimieren" nicht überprüft wurde, wurde der Code dennoch als optimiert kompiliert: Was nach dem Versuch alles half, war das Markieren des Kontrollkästchens "Nicht verwalteten Code-Debugging aktivieren" auf derselben Einstellungsseite (Projekteigenschaften - Debug). Es bezieht sich nicht direkt auf die Codeoptimierung, aber wenn diese Option aktiviert ist, optimiert VS meine Bibliothek nicht mehr und ich kann debuggen.

Ich hatte dieses Problem mit einem F # -Projekt, das hier und dort zwischen Visual Studio und MonoDevelop gewesen war und vielleicht von letzterem stammte (ich vergesse). In VS war die Optimierungsbox nicht aktiviert, jedoch schien die Optimierung für den Debugger offensichtlich zu sein. 

Nachdem die XML-Datei der Projektdatei mit der einer gesunden Datei verglichen wurde, war das Problem offensichtlich: Das gesunde Projekt hatte eine explizite <optimize>false</optimize>-Zeile, während es bei der fehlerhaften Datei völlig fehlte. VS schloss daraus offensichtlich, dass die Optimierung deaktiviert war, während der Compiler das Gegenteil tat.

Die Lösung bestand darin, diese Eigenschaft der Projektdatei hinzuzufügen und neu zu laden.

Ich hatte das gleiche Problem in VS 2010. Die Lösung wurde aufgeräumt und neu aufgebaut, und es funktionierte.

kommentar von vickramds, der sich auf http://torulflundgren.blogspot.com.au/2010/03/cannot-obtain-value-of-local-or.html bezieht, tat es für mich. Ich habe alles geprüft - alle DLL-, PDB-Dateien aus lokalen Bin-Ordnern gelöscht, Clean, Rebuild, alle Ordner der temporären ASP.NET-Dateien gelöscht, TRACE/DEBUG-Flags gesetzt, Pfade DLL usw. überprüft.

Um es abzulegen, damit es nicht verloren geht, für die betroffenen Projekte:

Projekteigenschaften -> Erstellen -> Erweitert -> Debug-Informationen: Vollständig.

Sie möchten prüfen, ob Sie die Debug-Konfiguration ausgewählt haben, bevor Sie dies tun, es sei denn, Sie beabsichtigen dies natürlich.

Ich erhielt diese Nachricht, als ich zu Visual Studio 2017 migrierte. Keine der Ideen auf dieser Seite, die ich ausprobiert habe, funktionierte für mich. In einem anderen Beitrag fand ich diesen Vorschlag und es DID funktioniert - entfernen:

[Assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]

... aus Ihrer AssemblyInfo-Datei.

Für mich war es in VS2017 und VS2019 passiert. Nachdem ich die Option "Unterdrückte JIT-Optimierung beim Laden des Moduls" ausgewählt hatte, passierte dies nicht mehr.

Wenn Sie versuchen, ein ASP.NET-Projekt zu debuggen, stellen Sie sicher, dass die Dropdown-Liste Eigenschaften> Web> Server des Projekts auf "IIS Express" gesetzt ist (zusätzlich zur Überprüfung aller anderen Bereiche).

Ich hatte gemischte c ++/cli-mfc-Erweiterungs-dlls, die auch bei der Debug-Konfiguration optimiert wurden (vom VS 2017-Modulfenster aus gesehen). Wie in der vorherigen Antwort vorgeschlagen, habe ich Folgendes geändert: "Gehen Sie in VS2013 zu" Extras -> Optionen -> Debugging -> Allgemein und aktivieren Sie "Verwalteten Kompatibilitätsmodus verwenden". Dadurch wird das Verhalten der neuen Funktionsbewertung deaktiviert. " Diese Einstellungen finden auch in VS 2017.

Aber das war nicht genug, also habe ich auch die UseDebugLibraries-Einstellung aus der Projektdatei einer anderen MFC-App in die Erweiterungs-DLL-Projektdatei kopiert.

    <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" Label="Configuration">
      ...
      <UseDebugLibraries>true</UseDebugLibraries>

Dann umbauen und das Problem behoben.