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.

Siehe

http://www.vmware.com/download/ws

Laut Release Notes unterstützt diese Version gegenüber der letzten Version (5.51 Build #19175) eine Reihe weiterer Betriebssysteme als Wirt und als Gäste und enthält Bugfixes. Neue Funktionalität gibt es augenscheinlich nicht.

Damit jeder 'mal sieht, was ich täglich so in Mission Control zu ertragen habe, hier mein kindischer Depp-uty in einer seiner typischen Posen:

Eine der größten Enttäuschungen, die mir meine VS2005 Professional bereitet hatte, war der Umstand, daß sie kein PreFast enthielt, so wie die Betas von VS2005, die ich zuvor getestet hatte und mit deren PreFast-Support ich so einige Bugs in meinem Sourcecode finden konnte. Es stellte sich nämlich heraus, daß der Prefast-Support nur in den ganz großen Ausgaben ("Enterprise-Edition"?) von VS2005 steckt, nicht aber in der immerhin 700 Euro teuren "Professional", die ich mir gekauft habe. Hhhmpff!

Jetzt habe ich mir aber spaßeshalber das aktuelle Vista PlatSDK (Build 5472) installiert und siehe da: Es hat PreFast-Support! Und so schaltet man sich den scharf, unter <PSDKPath> verstehe ich dabei den Pfad zum Vista PlatSDK:

Erstmal im Startmenü nach erfolgter PlatSDK-Installation den Eintrag "Register Windows SDK Directories with Visual Studio 2005" ausführen. Das ersetzt und ergänzt die per-User-Pfade für header files und libraries, so daß sie diejenigen des PlatSDK nutzen und nicht die der VS2005-Installation so wie sie OOB konfiguriert ist.
Dann VS2005 starten und unter "Tools"-"Options" links im Baum den Ast "Projects and Solutions" auswählen, dann "VC++ Directories". Dann in der Combobox mit dem Label "Show Directories for:" rechts oben den Punkt "Executable Files" auswählen, so dieses nicht bereits ausgewählt ist. In der großen Listbox in der Mitte ist bereits der Pfad <PSDKPath>\bin eingetragen. Wir erzeugen nun einfach einen neuen Pfad der da <PSDKPath>\vc\bin lautet und tragen ihn als zweitobersten ein. Dieser Eintrag führt dazu, daß der cl.exe von nun an aus <PSDKPath>\vc\bin gestartet wird.

Um nun ein Projekt mit Prefast zu übersetzen muß man jetzt nur noch die Projektsettings ergänzen und zwar so: Das Projekt im Solution Explorer anwählen, dann im Kontextmenü "Properties" anwählen. In dem Dialog, der dann erscheint, links im Baum "Configuration Properties"-"C/C++"-"Command Line" anwählen. Dann erscheint im rechten Teil des Dialogs eine Eingabezeile unten mit dem Label "Additional options:". Dort trägt man "/analyze" (natürlich ohne die Quotes!) ein. Nun buildet man sein Projekt und freut sich, daß man nun wieder Warnungen beim Builden bekommt. Denn eins sollte jedem klar sein: Ein Projekt, das nicht schon unter W4 warnungsfrei buildet, braucht man nicht mit PreFast übersetzen. Denn wenn's dazu schon nicht reicht, hat man meiner Meinung nach eh schon 'mal den falschen Job und andererseits interessiert derjenige Personenkreis, der reguläre Warnungen toleriert oder mit W0-W3 übersetzt, sich ohnehin in der Regel nicht dafür, den eigenen Sourcecode oder Implementierungstechniken zu verbessern. Das ist im üblichen ein sich selbst verstärkender Effekt.

Zwischenzeitlich ist ein Update meines Prefload-Tools entstanden, das rekursiv nach Dateien sucht, die überlappende bevorzugte Ladeadressen haben. An dieser Stelle hatte ich das Tool ursprünglich vorgestellt.

Die neue Version behebt einen peinlichen Bug: Die alte Version überprüfte nämlich nur ob Kollisionen zwischen DLLs vorhanden waren, aber nicht, ob nicht die bevorzugte Ladeadresse einer Datei auf 0x10000000 lag. Dies ist die Ladeadresse einer ungebasten PE-DLL. So konnte bei den zu prüfenden Dateien immer genau eine Durchschlüpfen, die ungebaset war, solange sie die einzige ungebasete war.

Ausserdem kennt die neue Version die Kommandozeilenoption "-i". Mit dieser Option werden alle gefundenen .NET-Assemblies unter den zu untersuchenden Dateien ignoriert. Das ist relativ geschickt, weil .NET-Assemblies by default alle an die Adresse 0x400000 geladen werden (also genau dieselbe, die standardmäßig eine native Exe-Datei hat, warum auch immer). Der C#-Compiler von MS (csc.exe) kennt zwar den Kommandozeilenschalter "/baseaddress:<address>", aber erstens weiß ich nicht, ob ungebasete .NET-Assemblies ueberhaupt ein Problem darstellen und zweitens haben die .NET-Junkies unter meinen Kollegen gerade ganz andere Probleme, als ihre Assemblies korrekt zu basen. Deswegen, und um meinem Buildmaster die Arbeit zu erleichtern (er muß sonst jedes neue .NET-Assembly in seine Ausschlußliste aufnehmen), ist diese Kommandozeilenoption todschick.

Die neue Version kann man hier downloaden.