Nun hat die Neugier doch gesiegt und ich habe auf meinem Entwicklungsrechner Visual Studio 2010 installiert. Man kann sich ja nur mit ein paar gesammelten Erfahrungen für oder gegen eine Sache entscheiden.

Bei der Installation gab es nichts zu bemängeln, alles lief sauber durch. Auch die AddIns Visual Assist und Tabs Studio waren schnell eingerichtet. Auf Tabs Studio bin ich über einen Pingback zum EasyTabs-Beitrag gestoßen. Tabs Studio bietet die wichtigsten Funktionen von EasyTabs. Etwas nachteilig ist lediglich, dass die Leiste nicht auch unten angeordnet werden kann. Aber daran könnte man sich sicher gewöhnen.

Große Ernüchterung brachte der Aufruf der Online-Hilfe, zu der Martin schon einen treffenden Beitrag geschrieben hat. Keine Ahnung, was Microsoft sich da wieder mal gedacht hat, wenn überhaupt. Alles läuft im Browser ab und somit natürlich auch außerhalb der IDE. Vermutlich verwenden bei Microsoft alle Entwickler mehrere Bildschirme und müssen nie in der Hilfe suchen.

Bei der Anpassung von Menüs und Symbolleisten geht Microsoft neue innovative Wege. Symbolleisten können per Maus nur noch an der jeweiligen Andockposition hin- und hergeschoben werden. Das Wechseln der Positionen (z.B. vom oberen Fensterrand an den unteren) ist nur noch per Dialog möglich. Aber auch das Hinzufügen, Entfernen oder Verschieben von Symbolen oder Menüeinträgen funktioniert nur noch über ein Dialogfenster. Die Maus ist immerhin noch dafür da, die entsprechenden Schaltflächen im Dialog anzuklicken. Ich bin gespannt, ob sich dieses neue Bedienkonzept auch in anderen Anwendungen durchsetzt.

Über die Darstellungsqualität des Texteditors kann ich mich nicht beklagen. Alles wird sauber dargestellt, auch ohne die ClearType-Einstellungen anpassen zu müssen. Erheblich verschlechtert hat sich aber leider wieder einmal die Makro-Performance. Ich habe mir schon zu VC6-Zeiten ein paar Makros geschrieben, die auf Knopfdruck diverse Kommentarblöcke in Quelltextdateien einfügen. Im VC6-Editor waren die Blöcke quasi schon eingefügt, wenn man das jeweilige Tastenkürzel losgelassen hat. Der Editor von Visual Studio 2008 brauchte für die gleiche Aktion schon etwas über zwei Sekunden, was aber von Visual Studio 2010 mit über sechs Sekunden locker übertroffen wird.

Aufgrund der fensterlosen WPF-Oberfläche ist das Scrollen eines inaktiven Fensters per Mausrad mit Hilfe von KatMouse nicht mehr möglich. Man muss immer erst in das Fenster klicken, welches man durchblättern möchte. Die Bearbeitung der globalen VC-Verzeichnisse für Header- oder Bibliotheksdateien im Einstellungsdialog wurde wegen der Umstellung auf das MSBuild-System abgeschafft, stattdessen muss man diese nun in den Eigenschaftsseiten eines Projekts bearbeiten. Dazu wählt man im Menü Ansicht den Eigenschaften-Manager und öffnet jeweils eine Win32- und x64-Konfiguration:

Über den Befehl Eigenschaften des Kontextmenüs öffnet man den Einstellungsdialog und kann nun die Verzeichnisse anpassen:

Die aktualisierten Eigenschaften-Dateien werden in den lokalen Eigenschaften des Benutzers (C:\Users\<Benutzername>\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.Win32.user.props bzw. Microsoft.Cpp.x64.user.props) abgelegt.

Zu dieser offiziellen Methode gibt es noch eine Alternative, mit der man die VC-Verzeichnisse systemglobal für alle Anwender ändern kann. Dazu öffnet man die beiden Dateien C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\PlatformToolsets\v100\Microsoft.Cpp.Win32.v100.props und C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\x64\PlatformToolsets\v100\Microsoft.Cpp.x64.v100.props und editiert die Pfade direkt. SpeedEdit kann auch Dateien in UAC-geschützten Verzeichnissen bearbeiten, bei Verwendung eines anderen Editors muss man die Dateien vor der Änderung erst in ein UAC-freies Verzeichnis kopieren und anschließend wieder zurückspielen.

Eine Konstante beim Erscheinen einer neuen Visual Studio-Version ist die Umstellung auf neue Projekt- und Arbeitsbereichsdateien. Die Konvertierung geschieht automatisch beim Öffnen eines alten Projekts oder eines Arbeitsbereichs. Dabei kann es passieren, dass Meldungen mit der Kennung MSB8012 angezeigt werden:

MSB8012: $(TargetName) (‘CxArj’) does not match the Linker’s OutputFile property value ‘..\..\lib\CxArj61u.dll’ (‘CxArj61u’) in project configuration ‘Release|Win32′. This may cause your project to build incorrectly. To correct this, please make sure that $(TargetName) property value matches the value specified in %(Link.OutputFile).

MSB8012: $(TargetPath) (‘D:\Visual C++\Dev\Libraries\CxArchiver\CxArj\.\objs\Release\CxArj.dll’) does not match the Linker’s OutputFile property value ‘..\..\lib\CxArj61u.dll’ (‘D:\Visual C++\Dev\lib\CxArj61u.dll’) in project configuration ‘Release|Win32′. This may cause your project to build incorrectly. To correct this, please make sure that $(TargetPath) property value matches the value specified in %(Link.OutputFile).

Das passiert, wenn im Projekt eine Ausgabedatei festgelegt wird, die sich vom Projektnamen selbst unterscheidet oder der Ausgabepfad für die Datei nicht dem eingestellten Ausgabeverzeichnis für das Projekt entspricht. Ich vermute mal, dass dieses gar nicht mal so selten vorkommt, da Zieldateien in der Debugversion häufig durch ein abschließendes “d” bzw. bei Erstellung von Ansi-/Unicode-Projekten durch ein zusätzliches “u” für die Unicode-Variante gekennzeichnet werden. Bei mir ist es z.B. so, dass alle Dlls in einem gemeinsamen Zielverzeichnis erstellt werden. Da ich aber nicht möchte, dass sich in diesem Verzeichnis auch alle .exp- und .lib-Dateien dieser Dlls tummeln, unterscheidet sich das Ausgabeverzeichnis des Projekts vom Zielverzeichnis der Dlls.

Die gleichen Warnungen werden anschließend auch beim Erstellen des Projekts angezeigt. Zur Auflösung des Konflikts wird empfohlen, den Projektnamen in den allgemeinen Konfigurationseigenschaften anzupassen. In Visual Studio 2010 gibt es dafür ein neues Feld für die Anpassung von $(TargetName). Allerdings muss man diese Änderung dann auch für alle Projekte in allen Konfigurationen durchführen. Wer also 100 Projekte mit jeweils vier Konfigurationen hat (Release/Debug für Win32/x64), darf unter Umständen 400x mal den Zielnamen anpassen, wenn der Name der Ausgabedatei nicht dem Projektnamen entspricht.

Allerdings ist es mir nicht gelungen, die zweite Warnung zum $(TargetPath) abzustellen, ohne das Ausgabeverzeichnis dem Zielverzeichnis gleichzusetzen. Fans der Holzhammer-Methode öffnen einfach die Datei C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets und entfernen in Zeile 982 den Text DoLinkOutputFilesMatch. Nachteilig ist dabei aber, dass die Variable $(TargetPath) dann nicht mehr der tatsächlichen Ausgabedatei entspricht, sondern stattdessen auf das in den Projekteigenschaften definierte Ausgabeverzeichnis zeigt. Wichtig ist das bei selbstdefinierten Build-Ereignissen, die man entsprechend anpassen muss, wenn man die Zieldatei nicht im Ausgabeverzeichnis ablegen möchte.

Nach der Konvertierung eines Arbeitsbereichs kann dieser mit Visual Studio 2008 nicht mehr geöffnet werden, wenigstens wird eine Sicherungsdatei angelegt. Will man mit beiden Versionen weiterarbeiten, dann muss man Arbeitsbereiche und Projektdateien doppelt pflegen. Vorsicht aber beim Einchecken in den TFS, da alle alten Projektdateien nach der Konvertierung automatisch aus der Quellcodeverwaltung gelöscht werden.

Mir persönlich fällt es sehr schwer, wesentliche Gründe zu finden, die für einen Umstieg auf Visual Studio 2010 sprechen. .NET 4 brauche ich nicht, die Hilfe-Funktion ist praktisch nicht mehr vorhanden und der neue historische Debugger funktioniert sowieso nur mit .NET-Code. Das erheblich verbesserte IntelliSense bringt mir auch keine Vorteile, da Visual Assist hier schon seit Jahren um Klassen besser ist. Die für einen C++-Entwickler wichtigen Neuerungen (Compiler, C/C++-Laufzeit und MFC) lassen sich zudem sehr einfach in Visual Studio 2008 einbinden.

Fazit: Bis zum Erscheinen von Visual Studio 2012 geht es erst einmal mit Visual Studio 2008 R2 weiter.