Umstieg 2: Visual Studio 2013

Seit mehr als sechs Jahren nutze ich nun Visual Studio 2008. Compiler- und bibliothekstechnisch war ich trotzdem auf dem aktuellen Stand, da sich die neuen Versionen relativ problemlos in die alte IDE einbinden lassen. Den Team Foundation Server (TFS) läuft schon in der 2010er-Version, aufgrund der Einbindung in die 2008er-IDE arbeitet man aber quasi auf dem 2008er-Niveau.

Die Entwicklung lief also quasi auf fest eingetrampelten Pfaden, was natürlich auch eine gewisse Stabilität verspricht. Trotzdem kam in den letzten Wochen der Wunsch nach etwas Veränderung auf. Also habe ich mir das nagelneue Visual Studio 2013 einmal etwas genauer angeschaut und getestet, ob ein Umstieg in Frage kommt.

Bei der wichtigsten Erweiterung Visual Assist waren keine Probleme zu erwarten. Auf meine EasyTabs muss ich natürlich verzichten, aber das Tabs Studio ist ein guter Ersatz. Ziemlich erstaunt war ich, als ich meine Makros übertragen wollte. Die Makrofunktionen waren nicht mehr zu finden und nach einer Netzsuche wusste ich, dass es seit Visual Studio 2012 keine Makros mehr gibt. Abhilfe schafft hier die Visual Commander-Erweiterung vom Tabs Studio-Autor. Meine VB-Makros konnte ich nahezu 1:1 übernehmen. Ab und zu fehlte nur ein DTE. für den Zugriff auf das Automationsmodell.

Der erste Kompilierungsversuch scheiterte allerdings an einer Exception in Microsoft.Build.Utilities.FileTracker. Die Ursache fand ich recht schnell im Netz. Mein Temp-Verzeichnis zeigt auf eine RamDisk, und zwar direkt auf das Hauptverzeichnis. Das mag MSBuild wohl gar nicht. Nach der Verlagerung des Temp-Verzeichnisses in einen Unterordner auf der RamDisk war das Problem behoben.

Die Fehlermeldungen im Zusammenhang mit den Zieldateinamen waren zu erwarten, schließlich habe ich die Erfahrung ja schon beim Test von Visual Studio 2010 gemacht. Die damalige Abneigung gegen die Vergabe von Projektnamen in den Projekteinstellungen hat sich nun in Befürwortung geändert. Bei konsequenter Verwendung des Projektnamens in den Compiler-/Linkereinstellungen braucht man bei Versionsänderungen (z.b. von MxFtp71 auf MxFtp72) diesen nämlich nur noch einer einzigen Stelle ändern. Früher musste man dagegen noch sämtliche Ausgabedateien anpassen.

Bei den gemeinsamen Bibliotheken verwende ich als Ausgabeordner der .dll-Dateien ein gemeinsames Verzeichnis. Hier unterscheidet sich der Zielpfadname mit Absicht vom Ausgabeverzeichnis des Projekts, was MSBuild jedesmal mit einer Warnung quittiert. Ein Löschen der entsprechenden Zeile 1186 aus Microsoft.CppBuild.targets schafft Abhilfe.

Als ordnungsliebender Mensch hat mich das neu angelegte ipch-Verzeichnis in jedem Arbeitsbereichsordner gestört, in dem die Datenbank für die IntelliSense-Daten abgelegt wird. Im Einstellungsdialog lässt sich unter Text-Editor | C/C++ | Erweitert im Bereich Ausweichpfad ein alternativer Pfad hinterlegen. Der Ausweichpfad zeigt bei mir nun auf ein Unterverzeichnis im lokalen AppData-Bereich und die Arbeitsbereichsordner sind ipch-frei.

Etwas verwirrend finde ich, dass im Projektmappen-Fenster vor den Quellcode-Dateien nun auch kleine Pfeile angezeigt werden und man die Quellcode-Dateien wie Ordner aufklappen kann. Aktiviert man auf der oben erwähnten Einstellungsseite im Bereich Durchsuchen/Navigation die Option Datenbank deaktivieren, dann verschwinden die Pfeile. Allerdings wird dann nur noch eine leere Ressourcen-Ansicht angezeigt. Eine Ressourcen-Datei kann dann nur per Rechtsklick mit Öffnen mit und dem Ressourcen-Editor geöffnet werden. Bei einem Gegentest mit Visual Studio 2010 zeigte sich das gleiche Problem. Entweder hat sich hier ein Fehler durch mehrere Versionen geschlichen oder das ganze ist ‚by Design‘.

Beim Erstellen der konvertierten Projekte gab es nur wenige Probleme. Die MFC enthält nun Makros für die Nachrichtenfunktionen WM_COPY  und WM_PASTE, damit konnte ich meine eigenen Makros für diese Funktionen löschen. Zudem wurden die Implementierungen für CWnd::OnDisplayChange und CWnd::OnPrintClient geändert. Hier muss man die Funktionen in den eigenen Klassen entsprechend anpassen. Das gilt aber nur, wenn die Projekte bereits auf dem VS 2012-Stand sind. Beim Konvertieren von älteren MFC-Versionen könnten auch mehr Korrekturen nötig sein.

Die Codeanalyse-Prüfungen im neuen Compiler wurden weiter aufgebohrt und es werden Sachen angemeckert, die der VS 2012-Compiler noch ohne Warnungen durchgewunken hat. Hier empfiehlt es sich, die Codeanalyse erst einmal temporär zu deaktivieren und die genaue Untersuchung auf einen späteren Zeitpunkt zu verschieben. Neu ist, dass die Regelsätze für die Codeanalyse nun auch angepasst werden können. Ob das in VS 2012 auch schon war, kann ich leider nicht sagen.

Von optischer Seite her macht Visual Studio 2013 einen sehr guten Eindruck. Die verwendeten Symbole sind zwar farblich sehr zurückhaltend, konzentrieren sich dadurch aber auf das Wesentliche. Besonders gut gefallen mir die synchronisierten Einstellungen über mehrere Rechner hinweg. Hier werden die Einstellungen für Darstellung, Tastenkürzel und Texteditor auf einem Microsoft-Server gespeichert und immer aktuell gehalten. Das erleichtert das Arbeiten an mehreren Rechnern enorm.

Sehr gelungen finde ich auch die Team Explorer-Ansicht innerhalb der IDE. Arbeitsaufgaben und ausstehende Änderungen sind immer im Blickfeld. Auch das Verknüpfen von Arbeitsaufgaben beim Einchecken geht ohne modale Dialoge sehr viel leichter von der Hand. Zu weiteren Erkundungen innerhalb der IDE bin ich noch nicht gekommen, aber ich freue mich schon darauf.

Etwas schade ist, dass der Remote Debugger nicht mehr auf Windows XP und Windows Vista läuft. Zu älteren Versionen des Remote Debuggers kann VS 2013 keine Verbindung mehr aufnehmen. Man kann zwar noch Anwendungen erstellen, die unter Windows XP laufen, diese aber nicht mehr auf Windows XP debuggen. Windows XP nähert sich also unaufhaltsam seinem Ende.