Überwachung lokaler Variablen "defekt"

  • VB.NET

Es gibt 12 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Überwachung lokaler Variablen "defekt"

    Gestern habe ich mal ein schon vor längerer Zeit begonnenes Projekt wieder rausgekramt und ein bisschen auf Vordermann gebracht. Vor allem im Hinblick auf die vielen Anregungen, die ich bisher in diesem Forum gesammelt habe, waren doch ein paar Änderungen und Umstrukturierungen notwendig. Das Projekt selbst hatte ich ursprünglich mit VS 2008 begonnen und irgendwann in den letzten 18 Monaten nach VS 2010 migriert.

    Vor ein paar Wochen schon ist mit im Zusammenhang mit diesem Projekt allerdings etwas aufgefallen, dem ich damals zunächst nicht allzu viel Besachtung schenkte, gestern aber habe ich es als extrem störend empfunden: Beim Debuggen wurde mir der Inhalt lokaler Variablen zum Verrecken nicht angezeigt. Das von mir oft genutzte und geschätzte MouseOver über die Namen lokaler Variablen im Quelltext während des Debuggens brachte keinerlei Reaktion, und der Versuch, eine solche Variable im Überwachungsfenster oder im Direktfenster anzeigen zu lassen, resultierte in der Meldung, das Element sei nicht deklariert, ggf. würde die Schutzstufe den Zugriff darauf verhindern.

    Membervariablen hingegen waren keinerlei Problem. Nur die innerhalb der Methoden deklarierten Variablen zickten derart herum. Eine vernünftige Fehlersuche oder Kontrolle des Ablaufs war mir so einfach nicht möglich.

    Ich suchte in den Projekteinstellungen, in den VS-Optionen, ob vielleicht irgendeine versehentlich aktivierte oder deaktivierte Einstellung für dieses Verhalten verantwortlich war - ohne Ergebnis.

    Witzigerweise war dieses Problem in dem anderen Projekt derselben(!) Projektmappe nicht existent. Also: Windows-Forms-Anwendung: kein Zugriff auf lokale Variablen durch den Debugger möglich, Klassenbibliothek in derselben Solution: alles normal. Das Programm selbst funktionierte - also auch keine Laufzeitfehler weil Variablen nicht deklariert wären oder sowas.

    Zur Probe fügte ich der Solution eine weitere Windows-Form-Anwendung hinzu, bei der ich probeweise nur im Form.Load-Event eine lokale Variable deklarierte und per Haltepunkt prüfte, ob der Debugger mir ihren Inhalt anzeigen kann. Das war ebenfalls kein Problem.

    Nun, am Ende habe ich das Problem "beheben" können, auch wenn die Ursache dafür mir bis jetzt vollkommen unbekannt ist. Gelöst habe ich es, indem ich das fragliche Projekt in ein anderes Verzeichnis verschoben, an der ursprünglichen Stelle ein komplett neues und frisches Windows-Forms-Projekt anlegte und alle Quellcode-Dateien aus dem verschobenen Verzeichnis dem neuen Projekt hinzugefügt habe.

    Und tatsächlich: Ich habe keinerlei Code geändert, schließlich auch alle anderen Projekt-Einstellungen manuell so angepasst, dass sie denen des bisherigen Projekts entsprachen (zumindest soweit ich aus dem UI von VS Zugriff darauf hatte), und fortan hatte ich beim Debuggen auch keinerlei Probleme mehr, mir lokale Variablen anzeigen zu lassen.

    Bleibt nur eine Kleinigkeit, weswegen ich schließlich hier poste: Was war die Ursache? Was kann dafür verantwortlich sein, wenn Visual Studio beim Debuggen lokale Variablen nicht anzeigen kann?
    Weltherrschaft erlangen: 1%
    Ist dein Problem erledigt? -> Dann markiere das Thema bitte entsprechend.
    Waren Beiträge dieser Diskussion dabei hilfreich? -> Dann klick dort jeweils auf den Hilfreich-Button.
    Danke.
    @Arby:: Das klingt sehr merkwürden.
    Kannst Du mal das alte Projekt posten?
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Zurzeit kann ich es nicht, weil ich jetzt im Büro bin und das fragliche Projekt zuhause auf meinem Rechner ist.
    Weltherrschaft erlangen: 1%
    Ist dein Problem erledigt? -> Dann markiere das Thema bitte entsprechend.
    Waren Beiträge dieser Diskussion dabei hilfreich? -> Dann klick dort jeweils auf den Hilfreich-Button.
    Danke.
    @Arby: Mir ist dieses Verhalten aufgefallen, wenn man in Projekte hineindebuggt, die nicht tatsächlich zur Projektmappe gehören. Also wenn die Struktur so in der Richtung aussieht:

    Quellcode

    1. Projektsammlung
    2. Projektmappe 1
    3. Projekt 1.1 -> Verweis auf die Release-Datei von Projekt 2.1
    4. Projektmappe 2
    5. Projekt 2.1

    Wenn Du in Projekt 2.1 einen Code wie diesen hast:

    VB.NET-Quellcode

    1. Public Sub Foo()
    2. Dim a As Integer
    3. If Irgendwas Then
    4. a = 1
    5. Else
    6. a = 2
    7. End If
    8. End Sub
    und Du diesen Code von Projekt 1.1 aus aufrufst, dann wird der optimierte Code ausgeführt. Wenn Du da durch debuggst, dann werden Sachen wie z.B. End If übersprungen, wo man normalerweise einen Schritt machen muss.

    Das könnte damit zusammenhängen.
    Das Projekt 2.1 in die Projektmappe 1 per "Hinzufügen -> Vorhandenes Projekt" aufzunehmen hat bei mir nur Probleme verursacht. Kann ich also nicht empfehlen.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    Niko Ortner schrieb:

    hat bei mir nur Probleme verursacht.
    Dem muss ich widersprechen. D musst nur die Build-Reihenfolge pflegen.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    @RodFromGermany: Das könnte das Problem sein. Ich musste immer zuerst das hinzugefügte Projekt markieren, dann auf "Erstellen -> Projektmappe erstellen" klicken (bzw. Strg+Shift+B drücken), und dann konnte ich wieder normal debuggen. Sonst hat's die Änderungen im Projekt nicht kompiliert. Ich bin schon oft genug Phantomfehlern hinterhergejagt :(

    Mal testen...
    Nope, hat leider nichts geändert.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils
    @Niko Ortner:: Hast Du hier bei Erstellen überall Haken gesetzt?
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    @RodFromGermany: Sowohl bei Debug alsauch bei Release sind alle Haken drin.
    Moment. Aber nur bei "Mixed Platforms". Wenn man auf AnyCPU oder x86 umstellt, fehlen einige Haken. Ich hab die mal gesetzt...
    Aaaach, na super. Jetzt funktioniert das, aber dafür hab ich dieses alte Problem wieder. Es wird nicht automatisch zwischen den konfigurationen umgestellt.
    Wenn ich die erweiterten Buildkonfigurationen wieder ausblende, dann funktioniert das Umschalten wieder, aber dafür wird das Projekt nicht mehr mitkompiliert.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils
    Bei mir zickt VS2010 gelegentlich in derselben Weise herum. Und noch unheimlicher: Projekt liegen gelassen, tagelang anneren Kram gemacht, zwischendurch auch Rechner runtergefahren und wieder hoch - nanu? jetzt gehts. 8|

    Manchmal stürzt sogar mein Rechner beim Debuggen ab, mit einem bluescreen - ich weiß nicht, ob das damit zusammenhängt.
    Vista SP1, 32 Bit, 2 Cpu-Kernels

    ErfinderDesRades schrieb:

    Vista
    kenn ich nicht (da bin ich auch heil froh drüber :thumbsup: )
    XP (32) und W7 (32, 64): keine Probleme.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    Na super... das Problem ist wieder da. Und nirgends im Netz finde ich was darüber. Alle Beiträge in denen es um angeblich nicht deklarierte Variablen geht und die ich finden konnte handeln tatsächlich von nicht deklarierten Variablen.
    Hab jetzt ein paar Mal mein Programm gedebuggt und ziemlich häufig auch per "Debug stoppen" abgeschossen und jetzt kann ich wieder nicht die Inhalte lokaler Variablen sehen oder im Direktfenster oder in der "Überwachen"-Liste anzeigen lassen. Ich krieg hier grad ne Krise, weil selbst ein Neustart von VS nicht hilft. Ich will nicht wieder die gesamte Projektmappe neu aufbauen ;(
    Weltherrschaft erlangen: 1%
    Ist dein Problem erledigt? -> Dann markiere das Thema bitte entsprechend.
    Waren Beiträge dieser Diskussion dabei hilfreich? -> Dann klick dort jeweils auf den Hilfreich-Button.
    Danke.
    vlt. bleibt bei dir eine vshost.exe im Speicher hängen - guggemol Task-Manager.

    Oder man müsste mal die versteckte mySolution.Suo - Datei löschen - die speichert, wo aktuell die Haltepunkte waren und so Sachen.

    Ist halt doof, dass man nicht richtig fahnden kann nach dem Fehler, weiler gelegentlich dann wieder weg ist :(

    Wenn man schonmal wüsste, wie man ihn ühaupt provoziert.