Schlagwort: Tipps&Tricks

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… 😉

Tipps & Tricks:EXE Dateien in der Eingabeaufforderung/Batches überall zugänglich machen ohne die Verwendung von PATH

Ich verwende sehr oft eine Eingabeaufforderung/Console/CMD.EXE/4-NT Session (wie man es auch nennen mag), weil vieles für mich einfach so schneller geht.
Zudem verwende ich eine Reihe von netten Helferleins (Tools), die zum Teil auch in meinen Buildprozessen integriert sind. Dort wird manchmal auch etwas gemacht was über ein TF CHECKOUT hinausgeht, oder was eben sowieso durch VS in den Path eingetragen wurde.

In den meisten Fällen nutze ich die normalen Installationsroutinen für diese Tools. Das Problem ist dann aber, dass diese Tools sich über X-C:\Program Files\Verzeichnisse verteilen.
Jetzt bei jedem Tool zu wissen wo es installiert ist übersteigt meine Kapazitäten und meine Lust die Pfade einzugeben. Es genügt, wenn ich weiß dass ich die Powertools des TFS mit TFPT aufrufen möchte, oder 7z.
Nun jeden dieser Pfade in PATH einzutragen ist ja wirklich auch nicht der Schreier. Das ganze wegen einer EXE…

Es gibt einen einfachen Weg sich Tools so zu behandeln, dass man sie von überall aufrufen kann. Dieser Weg ist in der Shell verborgen und lautet:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\
Jeder, der schon mal ein Installationsprogramm geschrieben hat kennt diesen Eintrag.

Was man zu tun hat ist ganz simpel: Man erzeugt einfach über RegEdit.exe in diesem Ast einen neuen Schlüssel mit dem Namen der EXE, die man gerne überall benutzen möchte (z.B. 7Z.EXE oder TFPT.EXE). Auf der rechten Seite als Standardwert trägt man einfach den vollständigen Pfad ein, wo diese EXE zu finden ist (in meinem Beispiel also: C:\Program Files\7-Zip\7z.exe oder eben C:\Program Files\Microsoft Team Foundation Server 2008 Power Tools\TFPT.exe).
So einfach kann es manchmal sein 😉

BTW: Leider geht das ganze nicht mit
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\!
Es gibt zwar einige dämliche Programme, die hier Eintragungen machen, allerdings haben die keine Wirkung.

Tipps & Tricks: Testcode sollte immer in #ifdef _DEBUG #endif Blöcke integriert sein!

Dieser Tipp hört sich trivial an, aber wenn man sich nicht dran hält erlebt man übelste Überraschungen.
Nur zu oft muss man während der Entwicklung oder bei der Fehlersuche Code einbauen, der Test, Ausgaben, Verzögerungen oder sonstige Operationen ausführt, die mir als Entwickler helfen ein Problem zu finden, oder einer Lösung für eine verzwickte Frage zu lösen. Um so größer das Problem wird um so mehr Stellen werden oft verändert.
Es bleibt die Frage ob sich jeder Entwickler noch erinnert wo er überall etwas für Testzwecke eingebaut hat.

Das üble Ergebnis ist, dass man manchmal toten nutzlosen, Performance fressenden Code ausliefert. Oder gar Code ausliefert, der evtl. zu neuen Fehlern führt. Da muss nur ein einfacher DebugBreak im Code zurückbleiben und schon crashed die Anwendung sauber beim Kunden…

Testcode sollte grundsätzlich in einem #ifdef Block eingebaut werden. Und Code der wirklich nur für Tests vorhanden ist und er sogar später in der Debug Version des Programmes nichts zu suchen hat sollte mit einem #else #error versehen werden. Ein ASSERT kann einen viel abnehmen um so etwas zu vermeiden, aber sogar mancher ASSERT  ist später überflüssig und behindert auch Tests in der Debug Version.

So habe ich in unserer Software einen Sleep(100); 😮 gefunden, der von einem Entwickler eingebaut wurde, um einen Crash in einem komplexen Kommunikationsproblem zwischen mehreren Threads zu finden.Er hat den Fehler gefunden, den Sleep aber nie wieder entfernt.
Hätte mein Kollege sich an meine Spezifikationen gehalten, hätten wir nicht nachträglich auf die mühsame Suche gehen müssen wo unsere Performanceverluste bei 5% Prozessorlast herkommen. So wäre das Ganze schon beim Release-Build aufgefallen:

#ifdef _DEBUG
// Test Sleep to find cross thread problems for bug#234
Sleep(100);
#else
#error Remove test condition here. Just used to find bug#234 
#endif

BTW: Ich verwende deshalb immer ein Code-Snippet über mein VisualAssist X, der mir einen entsprechenden Codeblock einsetzt.

VS-Tipps & Tricks: Command-Prompt öffnen im Projektverzeichnis

Es ist oft genug sinnvoll direkt im Projektverzeichnis eine Eingabe-Konsole zu öffnen. Ich persönliche verwende 4NT von JP-Soft, damit lassen sich viele Sachen weitaus schneller erledigen als mit dem Explorer.

Um schnell eine Eingabefenster zu öffnen kann man sich ein eigenes Tool einrichten.

  • Man klickt auf Tools -> External Tools…
  • Add Schalter anklicken
  • Dem Tool einen Namen geben (z.B. 4NT im Projektverzeichnis)
  • Als Command gibt man %COMSPEC% an
  • Als Argument /k „%VS80COMNTOOLS%\..\..\VC\vcvarsall.bat“ x86
    Durch diese Eingabe werden alle Environment Variablen gesetzt, die z.B. die Tools von VS2005 benötigen oder eben auch der Compiler. Dadurch kann man sofort alle Tools aus VS direkt von der Befehlszeile öffnen.
  • Bei Initial directory gibt man jetzt noch den Makro $(ProjectDir) an

Die entsprechenden Makros und Environment Variablen garantieren, dass die entsprechenden Batchfiles und auch der korrekte Befehlszeileninterpreter gefunden wird. Bei mir eben 4NT und nicht CMD.EXE. Durch die Verwendung von %VS80COMNTOOLS% wird auch der entsprechende Batchfile gefunden, egal wie das Programmverzeichnis heißt.

Der Aufruf von vcvarsall.bat setzt PATH, INCLUDE und LIB Environment-Variablen. Damit kann man alle VS-Tools diekt aus der Befehlszeile nutzen.

Warum ich diese komplizierte Methode gewählt habe? Ich liebe einfach universelle Angaben die man auf jeden Rechner übernehmen kann, egal wo die entsprechenden Softwarekomponenten installiert sind.

VS-Tipps & Tricks: Gruppieren von Tastaturbefehlen

Als Entwickler hat man schon viele Tastaturkürzel im Kopf. Viele sind jedoch nicht vordefiniert, also denkt man sich was eigenes aus. Dennoch gibt es Befehle, die man nicht so häufig benutzt und gerne auf der Tastatur ausführen möchte. Man vergisst dennoch, das Kürzel oder sogar wo man einfach den Menübefehl findet.

Oft ging es mir so, mit den Befehlen aus Visual Source Safe. Irgendwann habe ich für alle VSS-Befehle dann mal Kürzel angelegt. Aber keine 1 Tastenbefehle, sondern eine Sequenz.
Alle VSS-Befehle fangen bei mir mit Alt+V an. Dann folgt simpel und einfach der Befehl den ich VSS geben möchte:

  • Alt+V, O – Check out
  • Alt+V, I – Check in
  • Alt+V, H – Show history
  • Alt+V, E – Start VSS Explorer
  • Alt+V, U – Undo Checkout
  • Alt+V, G – Get lastest version
  • Alt+V, P – Show properties

So habe ich mit bestimmten Tastatursequenzen mir bestimmte Aufgabengruppen geschaffen, die einfach mit der ersten Sequenz die Gruppe definiert und mit der zweiten Taste, sinnvoll und einfach den Befehl auslöst. Die Lernphase ist extrem niedrig und man behält hunderte von Sequenzen im Kopf, weil man einfach weiß was man machen will.

Gleiches lohnt sich mit vielen netten Features aus Visual Assist (bei mir Alt+A) Gruppe. Oder auch für den Dialogeditor, dem man einfach bestehende Befehle einfachere und zusätzliche Tastaturkürzel gibt. Oder man erzeugt sich eine Gruppe von erweiterten Navigationsbefehlen (nächste Block, nächste Funktion etc.). Die Outlining Befehle sind ja schon unter Strg+M zusammengefasst, allerdings finde ich hier die Assoziationen für den zweiten Buchstaben nicht ganz so gut.
Es gibt noch viele wirklich gute Funktionen im Editor des Visual Studios, leider sind viele unerreichbar, weil die Tastaturbefehle abstrus sind oder gar nicht definiert sind. Es lohnt sich hier selbst auf Erkundungstour zu gehen.

VS-Tipps & Tricks: Schnelles Navigieren im Class View

Wenn man in Dialogen und Klassen über den Class View Variablen oder Funktionen hinzufügen will, dann ist dies oft mit mühsamen Rollen und suchen der Funktionen und Klassen verbunden.
Ganz besonders wenn man auch noch viele Namespaces verwendet.

Es gibt eine Funktion, der normalerweise kein Hotkey zugeordnet ist: View.SynchronizeClassView.

Der Name deutet es ja schon an, der Class View wird mit dem aktuellen Kontext synchronisiert.  Am Besten man weißt dieser Funktionen eine guten Hotkey zu und probiert die Funktion aus. Ich verwende hier Alt+A, S.

Diese Funktion zeigt den Class View an (auch wenn diese Tab-Seite aktuelle nicht aktiv ist), weiterhin wird sofort die aktuelle Klasse oder Funktion im Class View angezeigt, in dessen Kontext man sich aktuell befindet. Längeres Navigieren erübrigt sich.

VS-Tipps & Tricks: Direkte Befehlseingabe über Schnellsuche

Das Command-Window kennt man wahrscheinlich schon (Strg+Alt+A).
Man kann hier direkt über die Tastatur und mit Hilfe von Intellisense, das gesamte Visual Studio steuern. Das ist aber nicht unbedingt unbekannt wird aber selten benutzt.

Interessant ist, dass man sehr schnell ohne ein weiteres Fenster diese Befehlseingabe auch so benutzen kann. Über das Schnellsuch-Fenster.

Drückt man Strg+D, landet man in dem bekannten Eingabefenster im Toolbar in dem man nun nach etwas suchen kann. Aber dieses Fenster kann mehr. Gibt man nun das Größer-als-Zeichen > ein, dann kann man nun auch hier direkt einen Befehl mit der Zusatzhilfe von Intellisense ausführen.

Die Tastenkombination Strg+D > op Eingabetaste öffnet den Datei-Öffnen Dialog.
Mit der Tastenkombination Strg+D > va . opt kommt man an den VA Options Dialog.

VS-Tipps & Tricks: Kontextmenü auf Karteireitern

In der Newsgroup microsoft.public.de.vc kam die Frage auf, ob es eine Seite mit speziellen Tipps und Tricks gibt für Visual Studio. Meines Wissens nach gibt es so etwas leider nicht. Deshalb habe ich mir vorgenommen demnächst einzelne Tipps & Tricks hier zu veröffentlichen.
Eine komplette Sammlung und Übersicht ist dann über diese Seite oder über die Kategorie-Auswahl in meinem Blog möglich.

Wer etwas beizusteuern hat, kann gerne eine Email an mich senden.

Aber nun zum ersten Tipp: Kontextmenü auf Karteireitern

Es lohnt sich einen Blick auf das Kontext-Menü zu öffnen, das sich öffnet, wenn man mit der rechten Maus auf den Karteireiter einer offenen Datei im Visual Studio klickt. Dort gibt es drei äußerst nette Helferlein, die man leicht übersieht:

  1. Close All But This
    Schließt alle Fenster bis auf das aktive. Besonders gut noch einer Debugging Session um wieder etwas Übersicht zu bekommen.
  2. Copy Full Path
    Kopiert den kompletten Pfad der Datei auf die Zwischenablage.
  3. Open Containing Folder (Mein Favorit) ❗
    Netter und schneller kann man den entsprechenden Projekt Ordner im Explorer nicht öffnen. Besonders, wenn man seine Projektdateien in Unterverzeichnisse gegliedert hat kommt man hier ganz schnell an das entsprechende Explorer-Fenster.

Wie kann ich das Visual Source Safe Kennwort zurücksetzen?

Ja! Dieses Kennwort braucht man selten, aber wenn man es braucht hat man es vergessen.
Aber die UM.DAT zu hacken ist ziemlich simpel. Es gibt einige Anleitungen im Netz dazu.
Hier meine Vaiante die man mit jedem x-beibigen Hexeditor verwenden kann

  • Man sucht an den Adressen 0x84, 0xC4, 0x104, etc. den Benutzernamen Admin.
  • Hat man die Adresse gefunden z.B. 0x84 (was meistens der erste Benutzer Eintrag ist), dann geht man 0x20 Bytes weiter. In meinen Beispiel gelangen wir nun an die Adresse 0xA4.
  • Hier ersetzen wir einfach die nächsten 4 Bytes durch:
    0x90 0x6e 0x00 0x00

Das Kennwort ist nun leer! Man kann ein neues vergeben. 

PS: Es gibt andere Tipps, die ersetzen hier 6 Zeichen. Das sollte man unterlassen, denn die nächsten beiden Zeichen sind eine interne user ID.

PPS: Die extreme Sicherheit des Source Safe Kennwortes ist erkennbar an dem immens sicheren Hasing auf 32bit! 😀 Eine Brute Force Attacke per Batch zu betreiben sollte auch kein Problem sein…

BTW: Der Hack ist natürlich auf eigene Gefahr und sollte nur gemacht werden, wenn man auch eine Sicherung der UM.DAT hat!