Monthly Archives: July 2009

TFS: Check-In Kommentare automatisch in Source-Code einfügen

TFS ist ja was wunderbare… nur wer bisher ohne sowas gearbeitet hat, oder cvs genutzt hat, der hat meistens seine Änderungen direkt im Header/Footer seiner cpp/h-Datei reingeschrieben. Dies hatte den großen Vorteil, dass man direkt zwei Dateien vergleichen konnte und sofort gesehen hat, wer was gemacht hat.
Dies geht so mit dem TFS nicht. Man benötigt immer den Team Explorer (oder VS) um die Kommentare einer Änderung zu sehen.
Es ist also so nicht so einfach möglich “disconnected” zu arbieten und trotzdem zu jeder Datei die ganzen Änderungen (zumindest anhand den Kommentaren) zu erkennen.

Im cvs gab es sowas wie ein “keyword-substitution“. Damit konnte man z.B. “$log$” in einen Kommentar seines Source-Codes einfügen und das cvs hat beim Check-In automatisch den Kommentar in die Source-Datei eingefügt.

Sowas habe ich auch für den TFS gesucht aber nicht gefunden. Mir wurde an diversen stellen gesagt, das sowas nicht geht…

Jetzt habe ich mich gestern selber drangemacht es zu probieren 😉

Und voila: Es klappt…
Habe nun ein kleines VS-PlugIn geschrieben (Check-In Policy), welche beim Check-In in den TFS den Kommentar in die Source-Datei reinschreibt, wenn dort ein “$log$” Eintrag vorhanden ist.

Ich bin jetzt wirklich begeistert!
Das Ding tut einwandfrei… hab es jetzt sogwar soweit, dass man es ganz hübsch parametrieren kann; d.h. man kann ganz frei “Templates” vorgeben, wie die Kommentare aussehen sollen.

Hier mal zwei Beispiele:

Man kann die Kommentare entweder von oben nach unten einfügen lassen:

/**************************************************************
 *
 *  Description: ...
 *
 *  History
 *  -------
 *
 *    Date   |Author | Comment
 *  ---------+-------+----------------------------------
 *  24.07.09 | kalmb | sdfsdf sdfsdf sdfs
 *  24.07.09 | kalmb | Zeile 1
 *           |       | Zeile 2
 *           |       | Zeile 3
 *           |       | Zeile 4
 *  24.07.09 | kalmb | sdafsdgdgdfsgsdfgdfsgdsfgdfs
 *  24.07.09 | kalmb | fgd dsfgdfsgdsfgdfgd
 *  24.07.09 | kalmb | asdasdf sadfsfsfsdfasdfas
 *  $log$
 *
 **************************************************************
 */

Oder auch von unten nach oben (wie cvs):

/*
 * $log$
 * 
 * Comment: Nochmals eine Änderung
 * User: DOMAIN\name
 * DateTime: 2009-07-23 22:04:22
 * Change: edit
 * 
 * Comment: dsfsdfsdfsd
 *          sdfsdfgsdfhgf hdfhfdghdfghfgdh
 * User: DOMAIN\name
 * DateTime: 2009-07-23 22:00:36
 * Change: edit
 */

Aus meiner Sicht ist dies das beste PlugIn, was ich seit langem gesehen habe 😉

Was meint Ihr dazu?
Wer interesse hat, darf sich gerne bei mir melden…

EDIT: Gestern hab ich meine “Keyword Substitution Check-In Policy” auf Codeplex veröffentlicht: http://logsubstpol.codeplex.com/

Simples XAML führt mich zur Verzweiflung…

Wer schon mal extensiver mit XAML (WPF) zu tun gehabt hat, der weiss: Debugging von DataBinding ist nicht so ganz trivial…

Ich hatte heute einen ganz simplen Cut-n-Past Error: Habe ein Binding Expression der Form

in ein MultiBinding eingefügt… wer nun schon mal mit MultiBindings gearbeitet hat weiss, dass man dazu nicht die “Kurzform” mit den geschweiften Klammern verwendet, sonder das ganze in die “Elemente” reinschreibt… also aus dem obigen Beispiel wird dann ein


So… das sieht ja einfach aus 😉 jetzt hab ich aber beim Copy-and-Paste dummerweise die geschweifte Klammer am Ende mitkopiert… dann noch einige Zeit weitergearbeitet… und dann wollte ich starten… lies sich auch alles wunderbar compilieren…
Nach dem Start kam aber das böse Erwachen…. ich hab min. 1 Stunde gesucht (und dabei in den tiefen des .NET-Source-Codes debuggt) bis ich den Fehler gefunden habe.

Der Grund: Es kam nicht wie sonst üblich eine Debug-Ausgabe, dass er das Property “Test}” nicht finden kann!
Sondern es kam eine “System.FormatException”… so und jetzt Ihr 😉 (nein, das war schon die InnerException!)

Also, nach langem suchen hab ich tatsächlich ein Bug in WPF gefunden 😉
Wenn Trace-Ausgaben aktiv sind, dann wird der Text in “Path” einfach ungeprüft der StringBuilder.AppendFormat-Methode als Formatstring übergeben… da aber in meinem Fall eine geschweifte Klammer drin war, konnte der String natürlich nicht erfolgreicht formatiert werden… deshalb die Exception (die mir aber nun mal gar nicht weitergeholfen hat).

Hab es mal gemeldet:
VS2008-SP1: FormatException in MS.Internal.AvTrace if Binding.Path contains curly braces…
VS2010-B1: FormatException in MS.Internal.AvTrace if Binding.Path contains curly braces…

Bitte abstimmen, ob Ihr den auch wichtig findet… (ich persönlich finde ja das ganze Debuggen des DataBindungs hundsmiserabel).