Schlagwort: VA-X

Manchmal der letzte Retter in der Not: VA-X und die interne Historie

So geht es manchmal:

  • Da arbeitet man 4, 8, 12 oder 16 Stunden an einem Modul.
  • Alles sieht gut aus, nicht mehr lange und wir können einchecken.
  • Du änderst noch dies und das, steckst noch mal 2 Stunden Arbeit rein weil noch was optimiert werden soll und auf einmal merkst Du dass Du Dich verrannt hast. Die letzten 2 Stunden Arbeit hattest Du irgendwie das Gehirn nicht eingeschaltet, x-Änderungen gemacht, die nun alle Sch…sind.
  • Undo ist nicht mehr, weil Du schon andere Projekte offen hattest bzw. einmal VS abgeraucht ist.
  • Du hast Bockmist gebaut und jetzt willst Du auf den Stand von vor 4 Stunden zurück, oder den von gestern Abend.
  • Ein Shelveset hast Du im TFS nicht angelegt. Das machst Du nur wenn Du ins Wochenende gehst, oder Deinen Kollegen was weiterreichen musst.

Was nun? 😮

Als VA-X Benutzer (VisualAssist X http://www.wholetomato.com) hat man tatsächlich noch ein Backup!
Und zwar nicht nur eines, sondern ein paar.
In meinem History Ordner von VA-X
C:\Users\USER\AppData\Local\Microsoft\VisualStudio\10.0\Extensions\Whole Tomato Software\Visual Assist X\VERSION\Data\vs10\history\
werde ich fündig…

Ufff… :mrgreen:

Ich habe dieses Backup mittlerweile schon so oft verwendet, dass ich dazu übergangen bin diesen Ordner umzulegen an eine Stelle an die ich schneller dran komme. Das geht über den Registry Schlüssel HKCU\Software\Whole Tomato\UserDataDir.

Wer mehr dazu wissen will findet hier weitere Infos:
http://www.wholetomato.com/forum/topic.asp?TOPIC_ID=6865

Nachtrag (30.01.2012):
Damit diese Funktion auch verfügbar ist muss im VA-X die Auto Recovery Option eingeschaltet sein.
VA-X -> Options -> Performance -> Enable Auto Recovery

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: Kontextmenü für Refactor Befehle in VA-X ab Build 1557

Die Refactoring Befehle in VA-X sind ja schon länger bekannt und sind wirklich ein prima Feature (Build 1534 seit 09.2006).

Nur war es manchmal etwas trickreich an diese Befehle zu kommen. Meistens habe ich die Maus verwendet und über dem Symbol platziert und gewartet, bis das entsprechende Dropdown Symbol aus VA-X erschien. Intuitiv und schnell war das nicht.

Seit dem Build 1557 (052007) finden sich die Refactoring Befehle direkt als erster Menüpunkt im normalen Kontextmenü und sind damit auch über die Tastatur direkt mit der Kontextmenütaste (oder Umschalt+F10) zu erreichen. Ein Grund mehr sich diese Funktionen wirklich mal anzusehen. Sie sind wirklich einen Tipp wert!
Meine Favoriten im Refactoring Menü sind immer wieder Find References und Rename.

Und für alle die meinen ich habe was vergessen oder übersehen: 😉

  • Es gab zwar seit dem Build 1540 einen entsprechenden Befehl den man einem Hotkey zuordnen konnte, aber allzu viele Hotkeys passen in meinen Kopf auch nicht rein.
  • Ja und man kam an diese Befehle auch über Umschalt+Kontextmenütaste erhalten. Nur ist das komplette VA-X Menü leider etwas unaufgeräumt und groß.

Visual Assist X unter Vista mit VS2005 und SP1

Meine ersten Gehversuche und Test mit VS2005 unter Vista waren gut. Aber da ich mich ohne Visual Assist X gleich fühle als man man mir drei Finger an jeder Hand amputiert hat war ich sehr frustriert als ich merkte, dass VA-X nicht ganz so funktionierte wie es das sonst auf XP tat.

Ein ALT+G, also ein GotoDefinition lies nur einen lästigen Beep hören. Ich befürchtete ohne eine der Hauptfunktionen von VA-X auskommen zu müssen.

Nach einigen Tests merkte ich auch, dass VisualStudio 2005 auch nicht korrekt beendet wurde. Es war zwar nicht mehr sichtbar auf dem Monitor, aber im Taskmanager blieb die Applikation immer noch aktiv und lies sich nur durch den Taskmanager beenden.

Nun das ganze war kein Problem mehr, wenn man VisualStudio mit erweiterten Rechten (also mit Run as Administrator) startet. Aber genau das wollte ich nicht. Zudem mag ich keine überflüssigen Fragen beim Programmstart.

Nach kurzem Nachdenken war mir klar, dass VA-X seine Daten im Programm-Verzeichnis ablegt. Nun und das ist in Vista nun mal nicht gerne gesehen, denn auch als Administator hat man auf diese Verzeichnisse nur mit angehobenen Rechten Schreibzugriff.

Also habe ich die Rechte für das Verzeichnis C:\Programme\Visual Assist X einfach auch für den normalen Benutzer erweitert und auch Änderungsrechte vergeben. Und siehe da, alles funktioniert jetzt ohne Probleme.

BTW: Wer Visual Assist X nicht kennt, der sollte ganz schnell http://www.wholetomato.com besuchen und sich eine Demo besorgen.
Kein Tool mit dem ich arbeite ist so sehr sein Geld wert wie dieses!