[C#] Wurden Debugmöglichkeiten im Visual Studio eingeschränkt?

[Programmierer (Gast)]

Hallo,

ich habe zuvor VS2008 und XP 32 Bit genutzt. Jetzt habe ich umgestellt 
auf VS2012 und Win7 64 bit.

Vorher hatte ich sagenhafte Debugmöglichkeiten. Beispielsweise konnte 
ich die Ausführung anhalten (zB durch Breakpoint) den Code an der Stelle 
ändern oder den Ausführungscursor versetzen und einfach weiterlaufen 
lassen.
Mit dem neuen System muss ich komplett stoppen, ändern, neu compilieren.

Ich hoffe das war soweit verständlich.

Kennt jemand das Problem und den Grund?

Ich gebe mal folgende Auswahlmöglichkeiten:
[ ] Das gibt es noch, man muss es nur aktivieren etc
[ ] Das geht nicht im Visual Studio 2012
[ ] Das geht nicht mehr in Win7
[ ] Das geht nicht mehr mit 64 bit Systemen
[ ] Früher war alles besser

[Peter II (Gast)]

64bit Edit and Debug geht glaube ich erst in der 2013 Version.

http://blogs.msdn.com/b/habibh/archive/2009/10/12/how-to-edit-code-when-debugging-a-64-bit-application.aspx

[Programmierer (Gast)]

Danke für die schnelle Antwort.
Dein Link hat mich auf eine Idee gebracht.
Wenn ich in den Einstellungen des Platform target umstelle von "Any CPU" 
auf "x86" dann kann ich wieder den code zur Laufzeit ändern. Ist jetzt 
nicht ganz ideal, aber gut zu wissen.

[quappenkaul (Gast)]

> Wenn ich in den Einstellungen des Platform target umstelle von "Any CPU"
> auf "x86" dann kann ich wieder den code zur Laufzeit ändern.

Ist ja auch logisch: "Any CPU" bedeutet, dass das Programm auf 
x86-Windows im 32-Bit-Modus und auf x64-Windows im 64-Bit-Modus läuft 
(also beim Start des Programms der entsprechenden Maschinencode erzeugt 
wird).
Da Edit & Continue - wie Peter II bereits schrieb - für x64 erst ab VS 
2013 und .NET 4.5.1 unterstützt wird (s.u.), kann es mit älteren 
Versionen von VS unter Win7 x64 nur funktionieren, wenn du als Ziel 
explizit x86 angibst. Auf deinem XP x86 spielte das keine Rolle, da dort 
ja immer direkt 32-Bit-Code erzeugt wurde, wenn du das Programm zum 
Debuggen gestartet hast.

http://blogs.msdn.com/b/visualstudioalm/archive/2013/06/26/debugging-support-for-64-bit-edit-and-continue-in-visual-studio-2013.aspx

Etwas OT, aber vielleicht hilfreich:
Bevor du deine fertigen Programme weitergibst, solltest du wieder "Any 
CPU" einstellen (und natürlich damit noch einmal testen), um dem 
Compiler auf dem Zielrechner freie Hand zu lassen - es sei denn, du 
verwendest x86-Komponenten. Dadurch wird nur ein Flag im Header der 
Programmdatei anders gesetzt, welches dann später vom JIT-Compiler 
ausgewertet wird.
Man kann es mit CorFlags sogar einfach nachträglich ändern (z.B. wenn 
ein fremdes Programm auf einem x86-System entwickelt und per "Any CPU" 
erzeugt wurde, aber auf x86-Komponenten zugreift (und deswegen abstürzt, 
wenn es auf einem x64-System ausgeführt wird). Hat mir schon einige Male 
geholfen.

http://msdn.microsoft.com/en-us/library/ms164699%28v=vs.110%29.aspx

[Thomas (kosmos)]

Für Windows 7 hatte ich mal jemanden einen Patch aus dem Netz 
aufgespielt, danach könnte man die Windowsgrenze von 3 GBytes RAM bei 
32bit abhacken. Vielleicht wäre das Ne Lösung um 32bit Windows zu nutzen