Befehle des Menübands überspringen
Zum Hauptinhalt wechseln
SF Software-Beratung

Hier haben wir einen Tipp, der sich weniger an Administratoren als an Softwareentwickler richtet, die mit dem Microsoft Visual Studio 2008 Team Foundation Server (TFS) zur Quellcodeverwaltung arbeiten.

Um Nutzen aus diesem Artikel zu ziehen, sollten Sie TFS einschließlich des Build Servers einsetzen und administrative Kenntnisse in Windows oder Kenntnisse im Win32-API haben.

Wenn Sie

  • einen Microsoft Visual Studio Team Foundation Server 2008 einsetzen,
  • im TFS sowohl gemeinsam genutzte Bibliotheksprojekte als auch Anwendungsprojekte führen,
  • die Bibliotheksprojekte automatisch von der TFS-Buildserver-Komponente erstellen lassen und
  • die so erstellen Bibliotheken in die Anwendungsprojekte verteilen,

haben Sie vielleicht den Wunsch, beim Debuggen von Anwendungen auch in die Bibliotheksprojekte mitsamt Quellcodeansicht hineinzusteppen. Das Problem dabei ist, das Visual Studio 2008 auf der Entwicklermaschine die Quellcodedateien der Bibliotheksprojekte nicht findet, weil in denen die Pfade zu den Quellcodes notiert sind, wie sie auf dem Buildserver und nicht auf den Entwicklungsmaschinen gelten.

Gegeben sei etwa folgende TFS-Serverstruktur:

  • \TFS sei der Hauptordner der TFS-Struktur,
  • \TFS\Library\Source sei das Verzeichnis, in dem der Quellcode des gemeinsam genutzten Bibliotheksprojekts geführt wird,
  • \TFS\Application sei das Verzeichnis des Anwendungsprojektes,
  • \TFS\Application\Library enthalte die vom Buildserver (!) erstellten DLLs des Bibliotheksprojektes (in denen also Pfade auf den Quellcode enthalten sind, die auf der Entwicklermaschine gar nicht stimmen),
  • \TFS\Application\Source sei das Verzeichnis, in dem der Quellcode der Anwendungsprojekte gespeichert ist, welche die DLLs aus \TFS\Application\Library referenzieren.

Wenn Sie das Application-Projekt debuggen, können Sie dann nicht einfach auch in das Library-Projekt hineinsteppen. Dieses Problem in der einen oder anderen Form haben viele TFS-Nutzer, aber leider findet sich im Internet kaum eine Methode, wie man es wirklich angehen kann.

Auf dem Buildserver lautet der Pfad zum Quellcode der Bibliothek nämlich z. B. C:\TFS\Library - Main\Sources\Source, nämlich in der Form Workspace-Root, Buildbezeichnung, Sources und schließlich Source (wie im Projekt selbst). Das Problem sind die Buildbezeichnungen und die zusätzliche Ordnerhierarchie namens Sources, die vom Buildserver verwendet werden.

Auf der Entwicklungsmaschine heißt das Verzeichnis, in dem die Quellen der Bibliothek liegen, z. B. C:\TFS\Library\Source. Nun gibt es eine Diskrepanz zwischen den Ordnern auf dem Buildserver und auf der Entwicklermaschine:

C:\TFS\Library - Main\Sources\Source
C:\TFS\Library\Source

Beim Durchsteppen des Anwendungsprojektes wird Visual Studio nun in einem Verzeichnis C:\TFS\Library - Main\Sources\Source nach den Bibliotheks-Quellen suchen, die aber tatsächlich in C:\TFS\Library\Source verfügbar sind. Der erste Pfad ist der vom Buildserver in die Dateien geschriebene, die ja in \TFS\Application\Library kopiert und von dort im Anwendungsprojekt referenziert wurden.

Wir müssen also dafür sorgen, dass Visual Studio auf einen Pfad C:\TFS\Library - Main\Sources\Source zugreifen kann und darin die Dateien in C:\TFS\Library\Source sieht. Natürlich könnte man die Quellen immer in einen solchen Ordner hineinkopieren, aber elegant wäre das sicher nicht.

Auf aktuellen Windows-Betriebssystemen gibt es im NTFS-Dateisystem ein Feature namens Symbolic Links, mit dem man dieses Problem lösen kann. Dazu können wir etwa wie folgt vorgehen:

  1. Legen Sie den Ordner C:\TFS\Library - Main\Sources auf den Entwicklermaschinen an, bzw. den Pfad, wie er auf Ihrem Buildserver lautet. Nur den letzten Ordnernamen (hier Source) legen Sie nicht an.
  2. In dem so angelegten Ordner erzeugen Sie einen symbolic link namens Source (oder wie der Endordner bei Ihnen heißt), der auf C:\TFS\Library\Source zeigt.

Jetzt kann Visual Studio einfach auf den Pfad laut Buildserver zugreifen und bekommt gar nicht mit, dass es tatsächlich auf den Pfad laut Entwicklungsmaschine zugreift.

Bleibt nur die Frage: Wie legt man einen symbolic link an? Dazu kann man entweder Tools aus den Microsoft Windows Resource Kits verwenden, den Windows Server 2008-Befehl mklink oder selber ein kleines Tool schreiben. Der zugehörige Win32-API-Aufruf CreateSymbolicLink ist recht einfach zu nutzen. Wenn Sie möchten, können wir Ihnen unser Tool LinkUtil.exe senden. Beachten Sie nur, dass Sie den symbolischen Link standardmäßig nur erzeugen können, wenn Sie administrative Rechte auf der Entwicklermaschine haben. Verwenden können und sollten sie ihn natürlich ohne administrative Rechte.

Voilà.