VS Tipps & Tricks: WinMerge als DIFF-Tool in Verbindung mit TFS

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:

  • /x closes WinMerge if opened files are identical (after information dialog is shown). This parameter is useful when WinMerge is used as an external compare application. It helps to faster process and/or ignore files which don’t have any differences. Note that this option does not apply when files become identical when merging/editing them.
  • /e allows WinMerge to be closed with a single Esc keypress. This is useful when using WinMerge as an external compare application. WinMerge can act like an dialog which is easy and fast to close.
  • /wl initially opens left side as read-only. Use this when you don’t want to change left-side items in compare.
  • /ub tells WinMerge to not add both paths to MRU. External applications should not add paths to Open-dialog’s MRU lists.
  • /dl adds a description for left side shown instead of folder / filename. This allows showing version number or label for compared items. Like „Version 1.0“ or „Work Copy“.
  • /dr adds a description for right side shown instead of folder / filename. This allows showing version number or label for compared items. Like „Version 1.0“ or „Work Copy“.

Die entsprechenden % Platzhalter sind so durch Visual Studio vorbelegt:

  • %1 = Original file
  • %2 = Modified file
  • %3 = Base file
  • %4 = Merged file
  • %5 = Diff options
  • %6 = Original file label (label for %1 file)
  • %7 = Modified file label (label for %2 file)
  • %8 = Base file label (label for %3 file)
  • %9 = Merged file label (label for %4 file)

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.

Resümee bisher: Eine Übernahme aller Daten von VSS nach TFS mit VSSConvert kann man sich sparen

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:

  • Übernahme des aktuellen Programmstandes in das TFS System
  • Keine Übernahme der alten VSS Daten mit dem VSSConverter
  • Überarbeitung der Projektstruktur so dass, keine Datei-Shares mehr benötigt werden. Hierbei werden entsprechende übergeordnete Common Verzeichnisse verwendet.
  • Entzerrung der Gesamten Projektstruktur so, dass auch die Verwendung einer Master-Solution möglich wird.
  • Beibehalten der alten VSS Daten in einem Backup System, für evtl. Hotfixes der letzten Version und einige Legacy Projekte

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.

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&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

Zwei Tools, die die interne Kommunikation über den TFS noch einfacher machen…

Die Dokumentation, gehört bei uns zu dem Bereich, der nicht direkt mit der Entwicklung verbunden ist.
Ein Teil der Doku wird vorab von den Entwicklern entworfen, aber erhalten letzten Endes den Feinschliff von Anderen. Auch die weitere Pflege und auch die Übersetzungen werden nicht von der Entwicklungsmannschaft durchgeführt.

Eigentlich haben wir nur „everlasting“ Projekte haben, dass heißt unsere Projekte werden immer weiter gepflegt. Das ändert sich oft erst nach so nach 6-10 Jahren wenn sie in eine neues Produkt mit einem kompletten Redesign übergehen.
Das bedeutet auch für die Dokumentation eine immer wiederkehrende Überarbeitung. In der Vergangenheit, haben oft genug Verbesserungen nicht den Weg in die Doku gefunden, weil einfach vergessen wurde eine entsprechende Notiz zu schreiben.
Großes Erstaunen herrschte dann oft, wenn der Vertrieb ein Feature anmahnte, dass die Entwicklung schon längst implementiert hatte.

Mit der Einführung des Team Foundation Server (TFS) und Visual Studio Team Systems 2008 wollte ich auch den Informationsfluss an andere Firmengruppen verbessern, insbesondere zu den Personen, die die Doku schreiben und für die Publikationen der Updates zuständig sind.

Erreicht haben wir das durch zwei ganz einfache Schritte:

  1. Haben wir Visual Studio Team System Web Access 2008 SP1 Power Tool installiert, das als CTP vorliegt. Dadurch kann jeder einfach und simpel von jedem Rechner auf den TFS und die Workitems zugreifen ohne VS installiert zu haben.
    Die entsprechenden User wurden mit „Reader“-Rechten im TFS ausgestattet, sofern sie nicht sowieso schon zum Teil die Rolle eines Testers hatten.
  2. Habe ich das Team Foundation Server Event Subscription Tool installiert.
    Die Events die man über die Menüs in VS-2008 einrichten kann sind doch etwas dürftig.
  3. Mit dem Team Foundation Server Event Subscription Tool  habe ich dann zwei WorkItemChangedEvents eingerichtet, die bei einem Status „Closed“ (für Tasks) oder „Resolved“ (für Bugs), sofort eine Email mit dem entsprechenden Infos des Workitems an eine Emailverteilergruppe sendet.

Jetzt wird jeder „Close“ eines Tasks, bzw. jedes „Resolved“ eines Bugs sofort weiter gemeldet.
Die Mitarbeiter können sich über die entsprechenden Links, die Informationen aus dem Task oder Bug holen und die Dokumentation, Readme’s, Hilfedateien und Übersetzungen anpassen.

PS: Ja man hätte dies auch noch mit eigenen Projekt-Tasks und spezielen Statis regeln können, aber der Weg, so erschien mir einfach, simpel und praktikabel.

PPS: Im dem Team Foundation Server Event Subscription Tool  kann man übrigends noch andere sehr nützliche Benachrichtigungen erzeugen…

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.

TFS-2008: Your search cannot be completed because this site is not assigned to an indexer…

SharePoint und TFS sind ja was feines. Man kann ja mal ganz schnell seine Projekt-Doku durchsuchen. Aber 😮 was ist das

Your search cannot be completed because this site is not assigned to an indexer. Contact your administrator for more information.

Ok Kein Problem. Wahrscheinlich ist einfach der Suchdienst dieser Site nicht zugeordnet.

Also SharePoint 3.0 Central Administration öffnen -> Central Administration -> Application Management -> Content Databases  -> Datenbank auswählen -> und dort nun unter Select Windows SharePoint Services search server den Server mit dem Suchdienst auswählen. Aber 😮

Die ComboBox ist leer. Es gibt keinen Suchdienst.

Also nachsehen bei SharePoint 3.0 Central Administration öffnen -> Operations -> Services on Server 😮 Kann gar nicht sein!

Kein Such-Service installiert! Hier hätte ein für Windows SharePoint Services Search stehen müssen.

Bei der TFS Installation hatte ich einfach die Sharepoint Services 3.0 mit installieren lassen. Und bisher klappt auch alles prima. Also was machen?
Versuchen wir es mit einer Reparaturinstallation der Sharepoint Services 3.0. 😮 Fehler bei der Installation:

Microsoft Windows SharePoint Services 3.0 1033 Lang Pack — Error 1706. An installation package for the product Microsoft Windows SharePoint Services 3.0 1033 Lang Pack cannot be found. Try the installation again using a valid copy of the installation package ‚wssmui.msi‘.

OK! Dann noch Deutsches Sprachpaket heruntergeladen für die Sharepoint Services 3.0 -> Installieren -> Reparatur Installation für Sharepoint Services 3.0 durchführen.

Nun das ganze noch mal: SharePoint 3.0 Central Administration öffnen -> Operations -> Services on Server. Hurra!!!
Nun die Windows SharePoint Services Search starten.
Achtung: Wichtig ist, dass man einen Account als Reader angibt, der wirklich nur Read-Zugriff hat ❗

Starten und yeah… es geht… :mrgreen:

TFS-Reports und die Date/Time Picker mit den regionalen Einstellungen für Deutschland…

Wer Reports aus dem TFS in Visual Studio benutzt kann oft genug nicht die Date/Time Picker verwenden, wenn er die deutschen  regionalen Einstellungen verwendet.

Wenn man einen dieser Date/Time Picker benutzt wird das Datum im englischen Format in das Eingabefeld übernommen, was dann anschließend mit der Meldung

Der Wert, der für den ParamEndDate-Berichtsparameter angegeben ist, ist für dessen Typ ungültig. (rsReportParameterTypeMismatch)

quittiert wird.

Das ganze ist kein Problem des TFS sondern des MS-SQL 2005 Reportservers.
Es gibt für den MS-SQL 2005 SP2 einen nicht offiziellen Hotfix, der dies behebt:
http://support.microsoft.com/kb/949095/en-us

Leider muss man um ihn zu erhalten den Microsoft Support kontaktieren. Einfach dort den Hotfix anfordern. Mir ist nicht klar warum man diesen Hotfix nicht direkt herunterladen kann.

Weitere Infos auch hier:
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=271928

The project file ‚….vcproj‘ has been moved, renamed or is not on your computer. + Projects have recently been added to this solution. Do you want to get them from source control?

Bei der Umstellung meiner Projekte und Solutions von Visual Source Safe in den  TFS habe ich auch einige Projekte und Solutions umgruppiert.

Als ich dann ein bestehendes Projekt das bereits im TFS lag in eine bestehende Solution einfügen wollte, bekam ich in meinem Visual Studio 2005 die folgenden beiden Meldungen:

The project file ‚….vcproj‘ has been moved, renamed or is not on your computer.

Projects have recently been added to this solution. Do you want to get them from source control?

Und ich habe einige Zeit herumprobieren müssen um heraus zu bekommen was hier passierte. Erst habe ich versucht das Projekt heraus zu nehmen und wiedereinzufügen. Kein Erfolg. Neue Solution genommen, wieder das selbe.
Einiges Suchen im Netz brachte dann Hinweise auf die .suo Datei, die offensichtlich an dieser ganzen Geschichte schuld ist.

In dieser Datei werden lokal (nicht im Source Control) einige Einstellungen des Users für diese Solution gespeichert. Und diese war offensichtlich irgendwie mit falschen Informationen gefüttert bzgl. des Source Control Systems oder kam mit den alten Informationen nicht klar.

Die Lösung:

  • Projekt hinzufügen und es erscheinen die oben genannten Fehler 
  • Beide Fehler einfach ignorieren
  • Geänderte Solution Speichern mit dem hinzugefügten Projekt Speichern
  • Sulution schließen, oder besser gleich Visual Studio ganz beenden
  • Jetzt die <Solution>. suo Datei löschen
  • Dann Solution neu laden.

und alles ist gut…

VS Tipps & Tricks: Ganze Solutions zu einer Master-Solutions zusammenfügen

Wie andere Programmierer auch habe ich meine Projekte in einzelne Solutions zusammengefasst. Nicht wenige dieser Solutions haben auch komplexere Abhängigkeiten.

Bisher hatte ich insgesamt dann 4 größere Solutions, die alle Projekte dann für einen vollen Release-Build bündelten. Bisher wurden diese großen Solution-Builds, dann durch spezielle Batchfiles gesteuert. 

Seit ich den TFS (Team Foundation Server) verwende habe ich begonnen alle einzelnen Komponenten direkt auch auf das Buildsystem des TFS hin abzubilden. Dazu gehört auch, alle Projekte in einer großen Solution zusammenzufassen, um nun im Teambuild alles weitere ablaufen zu lassen.

Als ich mühsam Projekt für Projekt in eine große Master-Solution einfügen wollte machte ich eine nette Entdeckung:
Man kann nicht nur existierende Projekte in eine Solution einfügen. Nein! Es ist sogar möglich eine ganze Solution in eine bestehende Solution einzufügen und dabei sogar alle Abhängigkeiten in dieser Solution zu erhalten. Einfach im Dateidialog die Solutions auswählen und das war es auch schon.
Das macht es wirklich einfach auch komplexere Solutions in eine Master-Solution zusammenzufügen. Jetzt ist es auch nicht weiter schwer die verbleibenden Abhängigkeiten, die bei mir in dem Batch geregelt wurden zu definieren.

Langsame Ausführung von TF Befehlen auf der Befehlszeile

Ich verwende einige TFS Befehlszeilen Kommandos in Batchdateien unter anderem TF CHECKOUT und andere. Leider hatten die Befehle eine immens lange Ausführungszeit. Bis zu 20 Sekunden war keine Seltenheit. Wenn es schnell ging waren es 2-3 Sekunden. Mancher Batch lief bis zu 5 Minuten…

Eigentümlich, denn der TFS-Server liegt in meinem Netz, mein Rechner hat genug Power und der TFS-Server auch. Ein vergleichbarer Befehl aus der IDE dauert nur Sekundenbruchteile.

Das kann es ja nicht sein. Also gehen wir auf die Fehlersuche…
Gefunden habe ich die Lösung dann nach einigem Suchen in diesem diesem genialen Artikel von Buch Hodges

Check LAN connection settings (applies now and for RTM)

First, check your LAN connection settings in Internet Explorer (Tools -> Internet Options -> Connections -> LAN Settings).  Often, the best settings are either to have no boxes checked or to have both of the bottom two checkboxes checked, „Use a proxy server“ and „Bypass proxy server for local addresses.“  The reason is that the .NET 2.0 framework network code gets its settings from the settings in IE.  Prior to the December CTP, there was no way to override this.

How much difference does it make?  It makes a 1 – 2 second difference per tf.exe execution on our network.  Of course, these settings may not work on your network, either for tf.exe or IE, depending upon your network configuration; you’ll need to test it.

Beginning with the December CTP, there is an optional registry setting that you can use to tell the Team Foundation client to bypass the proxy server without changing your IE settings.  In HKCU (per user) or HKLM (global), you can create the registry entry Software\Microsoft\VisualStudio\8.0\TeamFoundation\RequestSettings\BypassProxyOnLocal of type string with the value „true“ to get the improved performance.

Also einfach in den Internet Explorer Optionen auf Internet Optionen -> Verbindungen -> LAN-Einstellungen gehen. Dort nun die beiden ersten Haken aus Automatische Suche der Einstellungen und Automatisches Konfigurationsskript verwenden herausnehmen.

Bei mir dauert nun ein entsprechender TF Befehl nur noch Sekundenbruchteile!

PS: Ich verwenden einen TFS-2008 mit VS-2005 auf den Clients. Also ist der Artikel für mich passend. Der Registry Eintrag der in dem Artikel erwähnt ist muss bei einem VS-2008 natürlich im Ast 9.0 gemacht werden.