Visual Studio 2005 hat ein von VS6 stark differierendes Verhalten, was das Customizen von Pfaden für Header, Libraries und Executables angeht. Dieser Blogpost soll hier etwas Licht ins Dunkel bringen.

Mit VS6 war die Welt schön und gut und einfach. Pfade konnte man kinderleicht ergänzen durch Manipulieren der named String Values unter

"HKEY_CURRENT_USER\Software\Microsoft\Devstudio\6.0\Build System\
Components\Platforms\Win32 (x86)\Directories"

Installierte man ein PlatSDK, so musste man hier normalerweise selber Hand anlegen und die Pfade ergänzen.

Ganz anders die Situation bei VS2005. Hier gibt es erstmal eine Reihe von XML-Dateien mit der Endung .config unter <vcinstalldir>\vc\vcpackages, pro Target (also x86, x64, CE, und VC-Express(?)) eine. Diese Dateien sind ab Werk erstmal generisch, enthalten also keine absoluten Pfade sondern arbeiten mit Platzhaltern ähnlich den Umgebungsvariablen. So wird etwa das VS2005 Installationsverzeichnis durch den String $(VCInstallDir) repräsentiert und andere Pfade durch ihre Environmentvariablen selber in äquivalenter Notation ($(SystemRoot), $(ProgramFiles), etc...).

Ändert man nun irgendwelche Einstellungen in VS2005 interaktiv, dann werden diese Einstellungen nicht in den o.g. .config-Dateien gespeichert, sondern es wird im Profil des Users eine Datei namens VCComponents.dat erzeugt.
Sie ist zu finden unter

"%USERPROFILE%\Local Settings\Application Data\
Microsoft\VisualStudio\8.0"

und ist eine UNICODE-Textdatei im Ini-Format (ich wußte es, INI wird niemals sterben!) und stellt einen per-User Override der .config-Dateien dar. Sobald also diese Datei im Profil des Users zu finden ist, wird für den entsprechenden User das VS2005 mit den dort eingetragenen Pfaden gestartet.

Soweit ist die Sache ja nun noch verständlich: Es gibt eine Ab-Werk-und-per-Maschine- Konfiguration in der .config-Datei, und eine optionale per-User-Konfiguration in VCComponents.dat im Profil des Users, statt wie früher bei VC6 im per-User-Registry-Hive. Dadurch daß man sich die letztgenannte Datei löscht, kommt man automatisch wieder zum Auslieferungszustand von VS2005 zurück, ist das nicht praktisch?

Spannend wird das Ganze aber, wenn man sich, wie ich unlängst, ein zu VS2005 passendes Platform-SDK installiert. Da gibt es zum gegenwärtigen Zeitpunkt nur das aktuelle Vista-Platform SDK. Installiert man dieses, so ändert sich erstmal überhaupt nichts. Denn um es verwenden zu können (außer Doku zu lesen), muß man ja erstmal dafür sorgen, daß eine installierte Version von VS2005 von diesem PlatSDK Wind bekommt. Das kann man old-fashioned machen wie früher, also die Pfade von Hand eintragen. Aber woher weiß ich denn wie eine amtliche Eintragung aller Pfade aussieht, inklusive Pfaden zu den neuen Tools, zum Framework SDK und pipapo? Bei früheren PlatSDKs war das einfach: include-Pfad und lib-Pfad ergänzen und fertig, aber jetzt mit diesem aufgeblähten Ungetüm von VS2005, dem neuen PlatSDK und dem .NET-Framework?

Da ist dann dieser Startmenüeintrag namens "Visual Studio Registration" - "Register Windows SDK Directories with Visual Studio 2005" schon sehr verführerisch, soll er doch sicherstellen, daß das installierte PlatSDK sauber und reibungslos in VS2005 integriert wird. Klickt man ihn nun also an, passiert folgendes:

• erstmal wird eine VCComponents.dat im Profil des ausführenden Users erbarmungslos eliminiert. Da gehen sie dahin, meine mühsam zusammengestoppelten Pfade...
• Dann werden in die .config-Dateien unter <vcinstalldir>\vc\vcpackages die neuen Pfade reingemergt. Von einem Backup der alten Dateien keine Spur. Meine Hoffnung ist ja, dass die Deinstallation dieses (Beta-)PlatSDKs alles wiederherstellt. Wenn nicht: Das war ja "Beta", ich wußte ja worauf ich mich einlasse...

Die Integration des Vista-PlatSDKs ändert also systemweit die Einstellungen für VS2005, man tut gut daran, sich vorher ein Backup der .config-Dateien zu machen (oder von einer Maschine herzukopieren, wo kein PlatSDK installiert ist) und sich von einer gegebenenfalls vorhandenen VCComponents.dat auch ein Backup zu machen. Gleichzeitig zeigt mir diese Vorgehensweise einmal mehr, daß man in diese beiden Dateien, wie auch in die Registry Keys für VC6, eigentlich selber nichts eintragen sollte, sondern eigene Header und Libraries immer über projektspezifische Pfadangaben ergänzen sollte, denn sonst kann man sich die Arbeit des Zusammenstopelns der Pfade jedesmal neu machen, wenn man ein neues PlatSDK installiert und ausprobiert, und kann vor allem nicht leicht durch Umkopieren der Datei VCComponents.dat mal mit und mal ohne das Platform-SDK oder mit mehreren PlatSDKs gleichzeitig hantieren. Wem das allzu abwegig vorkommt, dem sei gesagt, daß der derzeitige Buildprozeß bei επτ€σ nacheinander mit dem Windows-2000-PlatSDK von 1999, dem Windows 2003 Server PlatSDK vom Februar 2003, dem Windows 2003 Server SP1 PlatSDK vom Mai 2005 und Teilen des mit VS2005 ausgelieferten PlatSDKs übersetzt und linkt - und dies alles mit VC6-basierten Builds.