VS Tipps & Tricks: Wie schließt man ein Tool Window?

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.

HOWTO:Remote Debugging fast and easy

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. 

  1. Wir kopieren die Datei MSVSMON.EXE auf den Rechner auf dem wir Debuggen wollen:
    „C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe“
    Ja! Erstaunlich, mehr ist nicht notwendig.
  2. Beim ersten Start erhalten wir eine Warnung, dass wir die Firewall von XP SP2 oder Vista noch freischalten müssen. Gesagt getan.
  3. Nun wählen wir einfach die schnelle etwas unsichere Methode:
    Menü Tools -> Options
    In dem entsprechenden Dialog, wählen wir nun einfach:
    No Authentication (native only)
    Allow any user to Debug
    Port 4015 bleibt unverändert.
    Am Besten jetzt noch die Maximum idle time (seconds) von 900 auf was Brauchbares hoch setzen, sonst wird die Session einfach beendet nach 15 Minuten.
  4. Ja ❗ Das wars. Nun einfach im Visual Studio Tools -> Attach to Process wählen (Strg+Alt+P)
    Transport: Remote (Native only with no authentication)
    Qualifier: <Name des PCs den es zu debuggen gilt, oder IP-Adresse>
    Refresh
  5. WOW! Und schon sieht man seinen Prozess den man debuggen möchte.
  6. Jetzt nur noch auswählen und Attach

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

VS Tipps & Tricks: Schnellere Lernkurve durch sichtbare Tastatur Shortcuts

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.

VS Tipps & Tricks: Fehler in Custom Build Steps ermitteln

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.

TFS-2008 mit Visual Studio 2005 und anderen älteren Entwicklungssystemen benutzen

Ist man eigentlich gezwungen Visual Studio 2008 zu verwenden wenn man Team Foundation Server 2008 nutzt?

Nein! Wenn man Visual Studio 2005 und 2008 nutzt, wie auch ich für einige Projekte, dann kann man ohne weiteres trotzdem aus allen Systemen auf TFS-2008 zugreifen.
Man muss nur den passenden Team Explorer installieren. D.h. für Visual Studio 2005 installiert man einfach den Team Explorer 2005. Der 2005er Explorer steht übrigens auch kostenlos zum Download zur Verfügung, wer evtl. keine Version des TFS-2005 hat (http://www.microsoft.com/downloads/details.aspx?FamilyID=46473C2A-BB85-4461-BB27-4792A5DEF222&amp;displaylang=ja&displaylang=en)

Es ist klar, dass man in diesem Fall einige Features des TFS-2008 nicht benutzen kann, bzw. nur über den Team Explorer 2008. Aber das ist ja auch nicht weiter tragisch.
Tunlichst vermeiden sollte man aber neue Team-Projekte aus dem 2005er Explorer heraus anzulegen, das schlägt bei mir fehl.  Also neue TFS-Projekte zuerst im Team Explorer 2008 anlegen und dann mit Visual Studio 2005 bearbeiten.

Das Source Control System von TFS-2008 lässt sich übrigens mit den entsprechenden Microsoft Source Code Control Interface (MSSCCI). Ein entsprechendes Plugin gibt es hier zum Download: http://www.microsoft.com/downloads/details.aspx?familyid=faeb7636-644e-451a-90d4-7947217da0e7&displaylang=en. Diese Liste der unterstützen Systeme ist lang:

  • Visual Studio .NET 2003
  • Visual C++ 6 SP6
  • Visual Visual Basic 6 SP6
  • Visual FoxPro 9 SP1
  • Microsoft Access 2003 SP2
  • SQL Server Management Studio
  • Sparx Systems Enterprise Architect 6.1
  • Sybase PowerBuilder 10.5
  • Toad for SQL Server 2.0

VS Tipps & Tricks: Kontextmenüs in Visual Studio anpassen

Man kann ja ohne weiteres Toolbars und die Menüs in Visual Studio anpassen, was ich auch gerne nutze.

Besonders interessant ist es aber auch die verschiedenen Kontextmenüs anzupassen. Dazu muss man zu einem kleinen Trick greifen, denn die Kontext Menüs stehen normalerweise nicht automatisch im Zugriff beim Anpassen der UI.

  • Man wählt Tools -> Customize -> Toolbars
  • Dort dann Context Menus auswählen -> Kontextmenü

Es öffnet sich nun ein neuer Toolbar, in dem die Kontextmenüs alle erscheinen und können wie gewohnt angepasst werden.

Gar nicht schwierig, man muss nur wissen wie man dran kommt 😉

VS Tipps & Tricks: Verstecke Optionen in DEVENV.EXE: /AssociateFiles

Wer kennt das nicht: Man probiert einem neuen netten kleinen Editor aus, oder ein anderes Programm und wundert sich hinterher, dass bestimmte Dateiendungen nicht mehr mit den gewohnten Programmen verbunden sind…

Für Visual Studio gibt es hier einen netten undokumentierten Befehl, der es einem ganz einfach erlaubt, die Dateiverknüpfungen für Visual Studio wieder herzustellen ohne eine Reparaturinstallation fahren zu müssen.

Einfach DEVENV.EXE /AssociateFiles aufrufen.

Anmerkungen:

  • Dieser Befehl funktioniert sowohl in VS-2005 als auch VS-2008.
  • Es versteht sich von selbst, dass unter Vista dieser Befehl nur elevated (also als Administrator) ausgeführt werden kann. Also am Besten einen Visual Studio Command Prompt als Admin ausführen.
  • Dieser Befehl ist nicht direkt dokumentiert aber indirekt über eine Fehlermeldung in der Msdn und einige Change-Logs für VS-2005 SP1. So bin ich auf ihn gestoßen.

Tipps & Tricks:TFS Undo Checkout für einen anderen Anwender/Workspace erzwingen…

Für VSS hatte ich das entsprechende Vorgehen ja bereits unter diesem Artikel beschrieben: VSS Undo Checkout für einen Anwender den es nicht mehr gibt….

Während es im VSS nur eine Reaktionmöglichkeit hatte gibt es beim Arbietenmit dem Team Foundation Server gleich mehrere Szenarien und Möglichkeiten der Reaktion:

  • Ein Checkout muss rückgängig gemacht werden, weil ein anderer Benutzer einen exklusiven Checkout durchgeführt hat, dieser aber selbst nicht erreichbar ist.
  • oder man möchte nur den Checkout Lock zurücksetzen oder lockern und nicht den gesamten Checkout rückgängig machen
  • oder ein Mitarbeiter hat die Firma verlassen und alle entsprechenden Checkouts müssen zurückgerollt werden.

Zu jedem dieser Vorgänge gibt es eine spezielle Operation im TFS. Alle Operationen setzen voraus, dass man in dem entsprechenden Projekt administrative Rechte hat und alle Befehle müssen von der Befehlszeile aus eingegeben werden über TF.EXE.

Das mit diesen Befehlen nicht leichtfertig umgegangen werden sollte versteht sich hoffentlich von selber ❗

  1. Der Undo des Checkouts kann durch den folgenden Befehl erreicht werden:
    tf undo /workspace:BenutzerWorkspace;Benutzer $/Projekt/DateiName.cpp
    http://msdn.microsoft.com/de-de/library/c72skhw4
  2. Als Administrator hat man aber auch die Möglichkeit jede Form von Locks eines anderen Anwenders zu ändern. Das geschieht über die Befehlszeile mit:
    tf lock /lock:none $/Projekt/Dateiname.cpp
    http://msdn.microsoft.com/library/47b0c7w9
  3. Als letzter Holzhammer steht es einem Administrator offen einen Workspace eines Anwenders zu löschen. Dies löscht natürlich nicht die lokalen Dateien des Workspaces, führt aber dazu, dass alle Checkouts und alle Locks rückgängig gemacht werden. Diese letzte Methode eignet sich besonders dafür, die Daten ausgeschiedener Mitarbeiter aus dem TFS zu entfernen.
    tf workspace /delete WorkspaceName;DOMAIN\Benutzer
    http://msdn.microsoft.com/library/y901w7se

Evtl. muss noch mit der Option /s der Servername angegeben werden. Im Allgemeinen ist dies aber nicht notwendig. Für keinen der oben genannten Befehle ist muss man an den entsprechenden Rechner mit dem  betreffenden Workspace gehen um diese Befehle durchzuführen. Gerade das ist ja oft nicht möglich.

VS Tipps & Tricks: Goto Dialog im Class View

Eventuell ist dies auch gar kein Tipp für Euch, weil Ihr diese Funktion schon läääängst kennt. In diesem Fall ist dieser Artikel die Erkenntnis, dass ich (selbst nach Jahren intensiver Arbeit) immer wieder Funktionen entdecke, die ich gerne früher gekannt hätte ;). In diesem Fall habe ich ihn erst Anfang dieser Woche entdeckt.

Es ist eine Funktion, die nur MFC/ATL Entwickler nutzen können (oder Ihrer bedürfen):

  • Man hat ein MFC Projekt
  • Wähle im Classview eine von CDialog abgeleitete Klasse
  • Dann öffnet man das Kontextmenü
  • und findet den Befehl Goto Dialog

Führt man diesen Befehl aus, öffnet sich der Ressourcen-Editor mit dem entsprechenden Dialog.

Schön, dass es diese Funktion gibt, denn IDD_’s heißen oft genug so anders als die Klassen, dass es bei manchen großen Projekten immer erst eines Blickes in die Header Datei bedarf um den richtigen Dialog zu finden.

Wunderbar! Hätte ich diesen Befehl zuvor gekannt, dann hätte In den letzten Jahren bestimmt 10 Minuten Zeit sparen können, in denen ich verzweifelt Dialoge in den Ressourcen suche… 😉

Hotfix für UseMSPrivateAssemblies.h und VC-2008

Einige nutzen ja meine Lösung für private CRT und MFC Assemblies unter VC-2005, die ich in dem diesem Artikel unter Codeproject veröffentlicht habe
http://www.codeproject.com/KB/cpp/PrivateAssemblyProjects.aspx

Das Interesse und die Nachfrage ist groß dieses Verfahren auch unter VC-2008 zu nutzen.
Da ich aber aktuell wenig Zeit habe den Artikel komplett zu überarbeiten, veröffentliche ich den relevanten Code hier erst mal vorab als „Hotfix“. Dieser Hotfix setzt voraus, dass das aktuelle Feature Pack installiert ist. Der Code ist nicht auf die RTM Version hin zugeschnitten und getestet.

UseMSPrivateAssemblies.h

// Version 2.0 by Martin Richter [WWJD]
// Supports VC-2005 and VC-2008
#pragma once    

#ifndef RC_INVOKED
// Avoid problems with the resource compiler if included    

// This defines bock the creation in the header files
#pragma message("Using private assemblies for the MS runtimes")
#define _STL_NOFORCE_MANIFEST
#define _CRT_NOFORCE_MANIFEST
#define _AFX_NOFORCE_MANIFEST
//#define _ATL_NOFORCE_MANIFEST    

// The next statements block the linker from including object files in the
// CRT and the MFC, that would create manifest pragmas too.
#ifdef __cplusplus
extern "C" {            /* Assume C declarations for C++ */
#endif    

__declspec(selectany)       int _forceCRTManifest;
__declspec(selectany)       int _forceMFCManifest;
// __declspec(selectany)    int _forceAtlDllManifest;    

// The next symbols are used by the several versions of VC 9.0
__declspec(selectany)       int _forceCRTManifestRTM;
__declspec(selectany)       int _forceMFCManifestRTM;
__declspec(selectany)       int _forceMFCManifestCUR;    

#ifdef __cplusplus
}                        /* __cplusplus */
#endif    

// We use crtassem.h with the defines there. It just gives us the
// versions and name parts for the dependencies.
// Note that there is also a MFCassem.h but this include file has the
// manifest pragma's already in it. So we can't use it
//
// Three files are controlling this crtassem.h, MFCassem.h and atlassem.h!
// Happily __LIBRARIES_ASSEMBLY_NAME_PREFIX is used in CRT, MFC and ATL!
// Doing it right would need to use _MFC_ASSEMBLY_VERSION for the MFC
// but in fact _CRT_ASSEMBLY_VERSION and _MFC_ASSEMBLY_VERSION and
// _ATL_ASSEMBLY_VERSION are the same
//  - VC-2005 SP1 8.0.50727.762
//  - VC-2008 RTM 9.0.21022.8
//  - VC-2008 Feature Pack 9.0.30411.0 (used if _BIND_TO_CURRENT_VCLIBS_VERSION
//    and _BIND_TO_CURRENT_MFC_VERSION are defined to 1)    

#include <crtassem.h>

// We don't have a seperate block for the Debug version. We just handle
// this with a extra define here.
#ifdef _DEBUG
#define __LIBRARIES_SUB_VERSION    "Debug"
#else
#define __LIBRARIES_SUB_VERSION    ""
#endif    

// Manifest for the CRT
#pragma comment(linker,"/manifestdependency:\"type='win32' "                        \
    "name='" __LIBRARIES_ASSEMBLY_NAME_PREFIX "." __LIBRARIES_SUB_VERSION "CRT' "   \
    "version='" _CRT_ASSEMBLY_VERSION "' "                                          \
    "processorArchitecture='x86' \"")    

// Manifest for the MFC
#pragma comment(linker,"/manifestdependency:\"type='win32' "                        \
    "name='" __LIBRARIES_ASSEMBLY_NAME_PREFIX "." __LIBRARIES_SUB_VERSION "MFC' "   \
    "version='" _CRT_ASSEMBLY_VERSION "' "                                          \
    "processorArchitecture='x86'\"")    

// #pragma comment(linker,"/manifestdependency:\"type='win32' "                     \
//     "name='" __LIBRARIES_ASSEMBLY_NAME_PREFIX ".MFCLOC' "                        \
//     "version='" _CRT_ASSEMBLY_VERSION "' "                                       \
//     "processorArchitecture='x86'\"")    

// Manifest for the ATL
// #pragma comment(linker,"/manifestdependency:\"type='win32' "                     \
//    "name='" __LIBRARIES_ASSEMBLY_NAME_PREFIX ".ATL' "                            \
//    "version='" _CRT_ASSEMBLY_VERSION "' "                                        \
//    "processorArchitecture='x86' \"")    

#endif // RC_INVOKED

Anmerkungen:

  • Im Endeffekt sind nur 3 Zeilen (26-28) hinzugekommen.
  • Diese Version funktioniert sowohl für VC-2005 als auch VC-2008!
  • Unter Vista wird allgemein das Problem beobachtet, das private Assemblies nur genutzt werden können, wenn diese in einem Unterverzeichnis liegen. Liegen die Assembly Dateien im gleichen Verzeichnis wie die EXE kommt es zu einem Fehler „The application failed to initialize properly (0xc0000034). „ Dieser Sache bin ich (und andere) auf der Spur.
  • Es spielt für diesen Code keine Rolle ob die beiden Defines _BIND_TO_CURRENT_VCLIBS_VERSION und _BIND_TO_CURRENT_MFC_VERSION gesetzt wurden. Werden diese Defines auf 1 gesetzt bevor UseMSPrivateAssemblies inkludiert wird, dann werden die Manifeste so erzeugt, dass die Feature Pack DLLs gezogen werden. Sind diese beiden Defines nicht gesetzt werden Manifeste für die RTM Version erzeugt.
    Ich empfehle dringend diese beiden Defines zu setzen ❗

Das ist erstmal ein Schnellschuss für alle, die die es etwas eiliger haben.

Der Vorteil gegenüber der Lösung, bei der die Manifeste manuell bearbeitet werden, wie es zum Beispiel Jochen Kalmbach in seinem Blog vorgestellt hat ist klar:
Man muss eben nichts manuell machen 🙂
Es macht wieder alles der Compiler und Linker.