Auflösen von VSS Abhängigkeiten bei Continuous Integration mit Teamcity

Wer hat schon mal eine Visual Studio Solution erstellt und darin ein oder mehrere Projekte aus einer anderen VSS Location dazugehängt? Das Ganze ist ziemlich praktisch, weil man so erreichen kann, gewisse Funktionalität auszulagern und in einer eigenen Bibiliothek zusammen zu fassen (ich denk da an firmeninterne Bibiliotheken) – die man zentral im VSS ablegen kann und später bei jedem neuen Projekt einfach aus VSS heraus laden und verwenden kann.

Wo gibts jetzt ein Problem?

Problematisch wirds, sobald man das Projekt als CI laufen hat und dort unter anderem einen Build (Release || Debug) des Projektes erzeugen will.

Warum: Der Build Runner (Nant) ist nicht in der Lage, die logischen Abhängigkeiten, die im *.sln File angegeben sind, richtig aufzulösen. MSBuild geht beim Kompilieren davon aus, das auf einer gewissen Filelocation eigentlich eine VS Projekt Datei liegt, die das Tool aber dann nicht findet — klar, weil es nicht aus dem VSS geladen wurde (Visual Studio würde solche Abhängigkeiten erkennen und den Benutzer darüber informieren, dass er die Abhängigkeiten nachladen muss). Somit schlägt der Kompilier-Versuch fehl und der Build Runner beendet den Build mit irgendeinem Fehler.

Nicht gut, was tun?
Um diese Abhängigkeiten trotzdem aufzulösen gibts im Contrib-Projekt (http://nantcontrib.sourceforge.net/) für NAnt einen paar gute Tasks, die sich mit VSS beschäftigen:

• vssadd
• vsscheckin
• vsscheckout
• vssdelete
• vssget
• vsshistory
• vsslabel
• vssundocheckout

Für unser Problem verwenden wir “vssget”, da wir mit dem Task im die aktuelle Version einer Datei oder eines ganzen VS Projekts laden können. Konfiguration ist ziemlich einfach:

</p>
<property name="vss.user" value="tiger"/>
<property name="vss.password" value="woods"/>
<property name="vss.dbpath" value="\\servername\srcsafe.ini"/>

<vssget username="${vss.user}" password="${vss.user}" dbpath="${vss.dbpath}"
        recursive="true" replace="true" writable="false"
        localpath="Relative_LocalPath_On_BuildServer"
        path="$/Path_In_Source/" /><br />

Was erreichen wir damit: Wir laden ein Projekt aus dem VSS und legen es lokal auf dem Build Server ab, damit beim Kompilieren über den MSBuild Task (http://nantcontrib.sourceforge.net/release/latest/help/tasks/msbuild.html) alle Abhängigkeiten, die ja in der VS Solution bestehen, gefunden und aufgelöst werden können.

Ziemlich einfach — nur sollte man es wissen.
In diesem Sinne.