Gesammeltes aus dem Leben eines "normalen" Programmierers… :-)
Rund um die aktuelle Visual Studio Version
Die ganzen netten Tool-Windows (Memory Window , Watch Window, Find Result, Document Outline, Output, Pending Changes, etc.) kann man sich mit einer netten Tastenkombination auf den Monitor holen. Aber wie schließt man sie nun wieder?
Indem man mit der Maus rechts oben auf das rote X klickt… ❓ 😕
Nein ❗ Es geht auch (zum Glück) über die Tastatur. Mit Umschalt+Escape kann man jedes Tool Window sofort auf Hide setzen und schließen. Der entsprechende Makro Befehl lautet Window.CloseToolWindow.
Vor Jahren habe ich dazu bereits mal einen Artikel für VC6 veröffentlicht: Remote Debugging for Dummies! BTW: Es war überhaupt mein erster Artikel!
Also Zeit für ein kleines Upgrade.
Anmerkung: Mir geht es hier nur um natives Debuggen von C++ (also unmanaged Code), wen wird es wundern ? 😉
Für mich das ultimative Mittel der Qualitätssicherung und die beste Waffe für die Jagd auf den gemeinen Software-Bug ist und bleibt Remote Debugging.
Remote Debugging ist seit es Visual Studio 2002 gibt so einfach geworden wie noch nie. Und seit es Visual Studio 2005 ist es noch einen Tick einfacher geworden. Einziger Wermuthstropfen: Remote Debugging ist erst ab der Professional Version verfügbar.
Um so erstaunlicher wie wenig Entwickler dieses Werkzeug einsetzen.
Nehmen wir einfach mal den Fall, wir haben auf einer Maschine einen Crash, oder wir haben einen Zustand, den wir sofort Debuggen wollen. Geht das On-the-fly?
JA ❗
Wenn die Rechner in einer Domäne sind, gibt es meistens gar keine Probleme und man kann einfach wie folgt vorgehen.
So einfach geht es.
Wenn man die passenden PDB Dateien in Reichweite hat, kann man sofort Breakpoints setzen und am „lebenden Patienten“ operieren, als nur „post-mortem“ mit Crashdumps zu arbeiten.
Wie man gezielt auch die Projekteinstellungen nutzen kann, habe ich mir für einen späteren Artikel vorgemerkt. 😉
Siehe auch:
How to: Set Up Remote Debugging
Wenn man die BCG-Library oder MFCNext aus der VC++ 9.0 SP1 nutzt erhält man einen ASSERT wenn man ein CScrollView verwendet und wenn das Programm maximiert gestartet wird.
—————————
Microsoft Visual C++ Debug Library
—————————
Debug Assertion Failed!Program: …\Debug\TestSDIScrollView.exe
File: f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\viewscrl.cpp
Line: 385For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.(Press Retry to debug the application)
—————————
Abbrechen Wiederholen Ignorieren
—————————
Der Grund liegt darin, dass in der MFCNext Implementierung schon sehr früh ein RedrawWindow ausgeführt wird wenn das Main Window maximiert wird. In diesem Fall wird OnDraw/OnPaint bereits ausgeführt wenn SetScrollSizes noch nicht aufgerufen wurde. Das geschieht ja normalerweise meistens erst in OnInitialUpdate.
Dieser ASSERT soll dem Programmierer darauf hinweisen, dass SetScrollSizes unabdingbar für die korrekte Funktion des CScrollView notwendig ist.
Leider ist in diesem alten Code ein Seiteneffekt nicht berücksichtigt worden, der durch MFCNext in Spiel kam.
Das Ganze lässt sich jedoch einfach umschiffen indem man im Konstruktor seines Views vorab SetScrollSizes mit Dummywerten aufruft. Die eigentliche Initialisierung mag dann später wie gewohnt in OnInitialUpdate erfolgen.
CScriptEditorView::CScriptEditorView()
{
// If the program is launched maximized, a RedrawWindow occurs in a very
// early stage and OnDraw would be called without an initialized mapping mode
// So we just do a dummy init here.
SetScrollSizes(MM_TEXT,CSize(0,0));
}
Ich bin ein wirklicher Fan von WinMerge und deshalb nutze ich es auch als Ersatz für das Standard TFS Tool DiffMerge.exe. Wer noch nicht wusste, dass man hier ein eigenes Tool im TFS für Compare und Merge wählen kann, der findet die entsprechenden Einstellungen unter: Tools -> Options -> Source Control -> Visual Studio Team Foundation Server -> Configure User Tools
Um WinMerge für den Compare einzusetzen verwende ich die folgenden Parameter:
Program: C:\Programme\WinMerge\WinMergeU.exe
Arguments: /x /e /wl /ub /dl %6 /dr %7 %1 %2
Und folgende Parameter habe ich für den Merge eingestellt:
Program: C:\Programme\WinMerge\WinMergeU.exe
Arguments: /x /e /wl /ub /dl %6 /dr %7 %1 %2 %4
Hier eine Erklärung aus der Onlinehilfe von WinMerge für Befehlszeilenschalter, die ich aktuell verwende:
Die entsprechenden % Platzhalter sind so durch Visual Studio vorbelegt:
Leider muss man für jeden Datentyp sowohl Compare als auch Merge einzeln einstellen. Eine Default-Einstellung habe ich nicht gefunden.
Es gibt einen schönen Blogeintrag von James Manning, der auch noch andere Diff-Tools behandelt:
http://blogs.msdn.com/jmanning/articles/535573.aspx
Wie man sieht habe ich die WinMerge Parameter jedoch angepasst.
In manchen Fällen kommt man um Environment Variablen nicht herum. Sie machen es auch einfach, globale Pfade für Linker, Präprozessor und auch für die Ausführung (PATH) zu setzen, oder eben auch EXEs und DLLs zu steuern.
Solche Environment Variablen, bzw. INCLUDE und LIB Pfade zu setzen für das ganze System kann mühsam sein wenn man die Windows System UI nutzt. Der Aufruf ist umständlich und es erfolgt ein UAC-Prompt. Eine andere Variante wäre die Nutzung einer Reg-Datei. Dazu muss man aber wieder der UAC-Prompt über sich ergehen lassen.
Es geht viel einfacher, mit dem Helferlein SETX.EXE, das seit Vista nicht mehr nur im Windows Ressource Kit drin ist. Mit SETX kann man sich Ruckzuck ein kleines Batch-File schreiben, dass alle wichtigen Umgebungsvariablen für eine bestimmte Projektumgebung setzt.
Genial ist einfach, dass ab diesem Moment für jedes neu gestartete Programm diese Environment Variablen gelten. Natürlich inklusive der Visual Studio Umgebung.
In der Verbindung mit dem Aufruf von DEVENV /useenv kann man damit sehr schnell seinen Rechner auf eine komplett andere Projektumgebung einstellen. Und das ganze auch ohne UAC-Prompt 🙂 Ja! Man glaubt es kaum. Es erfolgt ja auch nur Zugriff auf HKCU.
Anmerkung:Ich benutzt sehr gerne den Property-Manager nur ist es eben nur eine Lösung für alle Software, die aus dem Visual-Studio heraus gestartet wird, und es nützt gar nichts, wenn man die EXE/DLL selber mit unterschiedlichen Umgebungen testen will.
Und SETX ist auch noch wirklich extrem flexibel. Man kann nicht nur einfach eine Environment Variable setzen, wie man es mit SET kennt. Als Quelle können hier sogar Tetxdateien, Registryschlüssel genutzt werden. Und das Multitalent SETX kann sogar bei Angabe von Computername, Nutzername und Kennwort remote benutzt werden und damit auch die Systemweiten Parameter verändern.
Hier die Beschreibung von SETX /?
SetX hat drei verschiedene Ausführungsmethoden:
Syntax 1:
SETX [/S System [/U [Domäne\]Benutzer [/P [Kennwort]]]] var Wert [/M]Syntax 2:
SETX [/S System [/U [Domäne\]Benutzer [/P [Kennwort]]]] var /K
Registrierungspfad [/M]Syntax 3:
SETX [/S System [/U [Domäne\]Benutzer [/P [Kennwort]]]]
/F Datei {var {/A x,y | /R x,y Zeichenfolge}[/M] | /X}
[/D Trennzeichen]Beschreibung:
Erstellt oder bearbeitet Umgebungsvariablen in der Benutzer- oder
Systemumgebung. Ermöglicht das Festlegen von Variablen, die auf
Argumenten, Registrierungsschlüsseln oder Dateieingabe basieren.Parameterliste:
/S System Remotesystem für die Verbindungsherstellung./U [Domäne\]Benutzer Bestimmt den Benutzerkontext, unter dem
der Befehl ausgeführt wird./P [Kennwort] Bestimmt das Kennwort für den
Auslassung fordert zur Kennworteingabe auf.Variable Bestimmt die zu setzende Umgebungsvariable.
Wert Bestimmt einen zu setzenden Wert
für die Umgebungsvariablen./K Registrierungspfad Bestimmt, dass die Variable auf Informationen
aus einem Registrierungsschlüssel basiert.
Gültiges Pfadformat:
Struktur\Schlüssel\…\Wert, z. B.
HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Control\TimeZoneInformation\StandardName./F Datei Bestimmt den Dateinamen der zu verwendenden
Textdatei./A x,y Bestimmt die absoluten Dateikoordinaten
(Zeile X, Element Y) als Parameter, nach denen
innerhalb der Datei gesucht werden soll./R x,y Zeichenfolge Bestimmt die relativen Dateikoordinaten im
Verhältnis zur „Zeichenfolge“ als Suchparameter./M Legt fest, dass die Variable in der
systemübergreifenden Umgebung
(HKEY_LOCAL_MACHINE) gesetzt werden. Der
Standardwert wird unter der Umgebung gesetzt
(HKEY_CURRENT_USER)./X Zeigt Dateiinhalte mit den x,y Koordinaten an.
/D Trennzeichen Bestimmt zusätzliche Trennzeichen, wie z. B.
„,“ oder „\“. Standardtrennzeichen sind
Leerzeichen, Tabulator, Wagenrücklauf und
Zeilenvorschub. Beliebige ASCII-Zeichen können
als zusätzliche Trennzeichen verwendet
werden. Die max. Anzahl an Trennzeichen,
einschließlich Standardtrennzeichen beträgt 15./? Zeigt diese Hilfe an.
HINWEIS: 1) SETX schreibt Variablen in die übergeordnete Umgebung
in der Registrierung.2) Auf einem lokalen System sind Variablen, die mit
diesem Programm erstellt oder bearbeitet wurden,
erst in zukünftigen und nicht in aktuellen
cmd.exe Befehlszeilenfenstern verfügbar.3) Auf einem Remotesystem sind Variablen, die mit
diesem Programm erstellt oder bearbeitet wurden, erst
bei der nächsten Anmeldesitzung verfügbar.4) Gültige Registrierungsschlüssel-Datentypen:
REG_DWORD, REG_EXPAND_SZ, REG_SZ, REG_MULTI_SZ5) Unterstützte Registrierungsstrukturen: HKEY_LOCAL_MACHINE
HKEY_CURRENT_USER (HKCU).6) Bei Trennzeichen wird zwischen Groß-/Kleinschreibung
unterschieden.7) REG_DWORD-Werte werden aus der Registrierung
im Dezimalformat extrahiert.Beispiele:
SETX MACHINE COMPAQ
SETX MACHINE „COMPAQ COMPUTER“ /M
SETX MYPATH „%PATH%“
SETX MYPATH ~PATH~
SETX /S System /U Benutzer /P Kennwort MACHINE COMPAQ
SETX /S System /U Benutzer /P Kennwort ^%PATH^%
SETX TZONE /K HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Control\TimeZoneInformation\StandardName
SETX BUILD /K „HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\CurrentBuildNumber“ /M
SETX /S System /U Benutzer /P Kennwort TZONE /K HKEY_LOCAL_MACHINE\
System\CurrentControlSet\Control\TimeZoneInformation\
StandardName
SETX /S System /U Benutzer /P Kennwort BUILD /K
„HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\
CurrentVersion\CurrentBuildNumber“ /M
SETX /F ipconfig.out /X
SETX IPADDR /F ipconfig.out /A 5,11
SETX OCTET1 /F ipconfig.out /A 5,3 /D „#$*.“
SETX IPGATEWAY /F ipconfig.out /R 0,7 Gateway
SETX /S System /U Benutzer /P Kennwort /F c:\ipconfig.out /X
Immer wieder kommt die Frage auf, warum sich ein Konsolenfenster kurz öffnet wenn man eine Windows Anwendung, wie z.B. Notepad mit den CRT Funktion system startet.
Die Antwort ist ganz einfach, dazu muss man einfach mal nicht einmal unbedingt einen Blick in die Sourcen werfen, denn es ist sogar richtig für system dokumentiert in der MSDN.
The system function passes command to the command interpreter, which executes the string as an operating-system command. system refers to the COMSPEC and PATH environment variables that locate the command-interpreter file (the file named CMD.EXE in Windows 2000 and later). If command is NULL, the function simply checks to see whether the command interpreter exists.
Also kurz und bündig: Es wird zwangsläufig immer ein Konsolenfenster geöffnet. Das verschwindet zwar sofort wieder, wenn man eine GUI Applikation startet, aber das kann man vermeiden indem man gleich ShellExecute verwendet.
Ganz anders sieht es mit der Doku bei _popen aus. _popen scheint sich anzubieten, um die Ausgaben eines Tools in eine Datei umzuleiten. Aber auch _popen nutzt wie system CMD.EXE /c (COMSPEC). Um das heraus zu bekommen muss man allerdings den Source Code der CRT zu Rate ziehen. Das bedeutet, dass auch bei Verwendung von _popen ein Flackern durch ein Konsolenfenster nicht ausbleibt.
Wie man es richtig macht, wenn man die stdin/stdout umleiten will findet man in den wohlbekannten Artikeln der MSDN http://support.microsoft.com/kb/190351 und http://msdn.microsoft.com/en-us/library/ms682499.aspx. Durch die Verwendung von CreateProcess lässt sich auch ganz vermeiden, dass der zweite Prozess angezeigt wird.
Wir haben Anfang des Jahres produktiv von Visual-Source-Safe (VSS) auf den Team Foundation Server (TFS) umgestellt.
Ich stand vor der Frage ob ich den bisherigen Source-Safe Inhalt komplett in den TFS übernehme und wie die eigentliche Migration auf den TFS möglichst schnell ablaufen kann.
In älteren Blog Artikeln habe ich ja bereits von dem Problem berichtet, dass wir sehr viel auch mit Shares unter VSS gearbeitet haben. Ich hätte hier sowieso tricksen müssen und die eigentliche Umstellung der Projekte in eine Struktur, die keine Shares mehr verwendet wollte ich dich lieber unter Nutzung des TFS durchführen.
Die Entscheidung viel also so aus:
Ich gebe zu, dass ich misstrauisch war. Auf die Historie des Source Control Systems nicht weiter als zum letzten Release zurückgreifen zu können erschien mir als großer Nachteil. Gerade weil wir hauptsächlich Projekte und Programmteile haben, die zum Teil schon auf 20 Jahre Geschichte zurückblicken und immer noch weiter entwickelt werden.
Letzten Endes haben aber alle Team Mitglieder bisher klar gesagt: „Schade, dass wir diesen Schritt au den TFS nicht eher gemacht haben“.
Im Nachhinein vermisst keiner die gesamte VSS Historie, der Projekte. Wer muss, der kann noch im alten VSS Backup-System stöbern. Aber das war bisher nur in einem einzigen Fall wichtig und hilfreich.
Ich kann aus meiner Sicht also dazu raten, einfach einen Cut mit dem aktuellen System zu machen und mit dem aktuellen Programmstand einfach in das TFS System einzuchecken und einzutauchen. Sich zwei Tage und mehr mit dem VSSConvert herumzuschlagen (wie ich es zum Teil schon gehört habe), ist aus meiner Sicht heute vertane Zeit.
Wie kann man eigentlich lernen noch schneller mit Visual Studio umzugehen?
Ein Weg ist sicherlich die Maus zu umgehen und mehr mit der Tastatur zu machen. Dazu ist es aber auch notwendig, die entsprechenden Tastaturbefehle zu kennen.
Ein einfaches Hilfsmittel ist es die Tastatur Shortcuts auch in den Buttons der Toolbars anzeigen zu lassen. Das geht einfach über Tools -> Customize -> Show shortcut keys in ScreenTips.
Die Tooltips der Buttons enthalten, dann auch den Shortcut, der diesen Befehl auch auslösen würde. Auf diese Weise erhält man z.B. schnell die Info, dass Strg+D in das Suchfeld springt.
Die englische Version des Microsoft SQL Server 2008 wurde gestern am 06.08.2008 veröffentlicht.
Auf der Startseite der MSDN Subscriptions findet sich folgende hoch interessante Information:
SQL Server 2008 RTM Available for Download
English downloads are available now and additional languages will be added on a daily basis. Visual Studio 2008 users will need to download and install Service Pack 1 which will be available here after August 11, 2008.
Das heißt, dass wir ab Montagmorgen mit dem finalen SP1 für Visual Studio 2008 rechnen dürfen, zumindest in der englischen Version. Ich befürchte, dass die deutsche Version noch ein paar Tage mehr auf sich warten lässt.
Wie immer ein Grund nur mit den englischen Entwicklungswerkzeugen zu arbeiten 
Manchmal macht man ja schon komplexere Sachen in den Custom-Build-Steps, wie zum Beispiel auch das Erzeugen der HTML-Help Include Datei. Aber es geht ja noch viel komplizierter, zumindest benutze ich solche komplexen Custom-Build Funktionen ziemlich häufig!
Was nun, wenn man eine Fehlermeldung erhält in solch einem Custom-Build-Step, aber gar nicht weiß wo der Batch eigentlich aussteigt, oder was er gerade getan hat ❓ Besonders wenn die Ausgabe im Build-Fenster so informativ ist wie:
Das System kann den angegebenen Pfad nicht finden.
Das eigentliche Problem ist, dass die Batch-Zeilen bei der Ausführung nicht angezeigt werden.
Man könnte meinen, dass Visual Studio dies mit einem mystischen Trick macht. Sieht man sich jedoch die Build-Log Datei an, so sieht man, dass vor einen Custom-Build-Step einfach immer ein @echo off eingebaut wird.
Was spricht eigentlich dagegen als erste Zeile ein @echo on in den Custom-Build einzusetzen? Nichts!
Gesagt getan!
Die Folge: Jede Zeile des Batches, der im Custom-Build durchlaufen wird, erscheint brav in der Build-Ausgabe. Einen Fehler zu finden, bei man z.B. einen Pfad falsch mit Makros zusammengebaut hat ist nun denkbar einfach.