Visual Studio 2013

Die bevorzugte Schriftgröße für den Texteditor lässt sich bekanntermaßen im Einstellungsdialog ändern. Manchmal würde man aber gerne eine Zwischengröße verwenden, weil 8 Punkte zu klein und 9 Punkte zu groß sind. Allerdings werden nur Ganzzahlen akzeptiert und man muss sich für eine Größe entscheiden.

Hier könnte das Zoom-Eingabefeld am unteren linken Rand des Texteditors weiterhelfen, mit dem man die Schriftgröße viel feinstufiger anpassen kann. Könnte helfen, denn Visual Studio öffnet jedes neue Fenster mit 100%, ein Standardwert lässt sich nirgends vorgeben. Eine ständige Korrektur der Zoom-Größe bei jedem neuen Fenster ist natürlich auch keine praktikable Lösung.

Abhilfe schafft die TroutZoom-Erweiterung. Einmal installiert merkt sie sich den zuletzt eingestellten Wert und sorgt dafür, dass neue Fenster immer mit dieser Zoom-Größe geöffnet werden. Zudem werden bei einer Änderung der Größe automatisch auch alle anderen geöffneten Fenster angepasst. Der Quellcode für die Erweiterung ist auch verfügbar. Wenn man sich den Quellcode mal anschaut, dann fragt man sich, warum die 10 Zeilen nicht gleich Bestandteil von Visual Studio sind.

Viele Entwickler bevorzugen für die Ausgabe von kompilierten Dateien ihre eigene Verzeichnisstruktur. Ich selbst habe jahrelang in jedem Projektordner ein Verzeichnis objs verwendet, welches noch einmal jeweils einen Unterordner für jede Konfiguration (Debug, Release, …) enthielt. Zum Löschen aller Ausgabedateien reichte in FileSearch eine Suche nach objs mit dem anschließendem Löschen aller gefundenen Ordner.

Mit dem Umstieg auf dem Mac musste ich mich aber von diesem System verabschieden. Der Grund war die stündliche automatische Sicherung mit TimeMachine. Die Ausgabedateien belegen pro Entwicklungszweig insgesamt bis zu 10 GB und ändern sich mit jedem Compilerlauf. Eine stündliche Sicherung würde auf dem Backupmedium schnell einen Engpass erzeugen. Man kann zwar Verzeichnisse von der Sicherung ausnehmen, muss diese aber genau benennen. Bei knapp 50 objs-Ordnern pro Entwicklungszweig ist das aber eher eine mühselige und fehlerträchtige Aufgabe.

Die Lösung war ein gemeinsamer Basisordner für die Ausgabedateien jedes Entwicklungszweigs auf dessen oberster Ebene. Die Ausgabe- und Zwischenverzeichnisse für jedes Projekt änderten sich so von

objs\Release_x64

auf

..\..\!IntDir\SpeedCommander\$(ProjectName)\Release_x64\

Anschließend mussten in der TimeMachine nur noch zwei !IntDir-Verzeichnisse für die Dev/Main-Entwicklungszweige als Ausnahme eingetragen werden.

Ein eher unschöner Nebeneffekt waren allerdings die relativen Bezüge in den Pfadnamen für die Ausgabedateien im Ausgabefenster. Statt

2>     Bibliothek "objs\Release_x64\CxLib72.lib" und Objekt "objs\Release_x64\CxLib72.exp" werden erstellt.
2>  CxLibrary.vcxproj -> D:\Visual C++\Dev\Libraries\CxLibrary\objs\Release_x64\CxLib72.dll
...
3>  sqc.vcxproj -> D:\Visual C++\Dev\SpeedCommander\sqc\objs\Release_x64\sqc.exe
3>  Done Adding Additional Store
3>  Successfully signed: D:\Visual C++\Dev\SpeedCommander\sqc\objs\Release_x64\sqc.exe

wurde im Ausgabefenster nun

2>     Bibliothek "..\..\!IntDir\Libraries\CxLibrary\Release_x64\CxLib72.lib" und Objekt "..\..\!IntDir\Libraries\CxLibrary\Release_x64\CxLib72.exp" werden erstellt.
2>  CxLibrary.vcxproj -> D:\Visual C++\Dev\Libraries\CxLibrary\..\..\!IntDir\Libraries\CxLibrary\Release_x64\CxLib72.dll
...
3>  sqc.vcxproj -> D:\Visual C++\Dev\SpeedCommander\sqc\..\..\!IntDir\SpeedCommander\sqc\Release_x64\sqc.exe
3>  Done Adding Additional Store
3>  Successfully signed: D:\Visual C++\Dev\SpeedCommander\sqc\..\..\!IntDir\SpeedCommander\sqc\Release_x64\sqc.exe

angezeigt. Aber auch nach knapp sechs Monaten konnte ich mich an diese Darstellung nicht so recht gewöhnen.

Auf der Suche nach einer Lösung bin ich auf diese Seite gestoßen, auf der die Funktion $([System.IO.Path]::GetFullPath(“)) genannt wird. In den Tiefen der MSBuild-Umgebung habe ich dann die Datei Microsoft.cpp.targets gefunden, in der die Werte für Ausgabe- und Zwischenverzeichnis validiert werden. Gleich nach der Prüfung auf den abschließenden Backslash habe ich in Zeile 34 die folgenden Zeilen eingefügt:

  <PropertyGroup>
    <IntDir Condition="!$([System.IO.Path]::IsPathRooted('$(IntDir)'))">$([System.IO.Path]::GetFullPath('$(ProjectDir)$(IntDir)'))</IntDir>
    <OutDir Condition="!$([System.IO.Path]::IsPathRooted('$(OutDir)'))">$([System.IO.Path]::GetFullPath('$(ProjectDir)$(OutDir)'))</OutDir>
    <OutputPath>$(OutDir)</OutputPath>
  </PropertyGroup>

Diese sorgen dafür, dass die aus dem Projektverzeichnis und den dazu relativen Ausgabe- und Zwischenverzeichnissen zusammengesetzten Pfade keine überflüssigen Verweise mehr enthalten.

Beim nächsten Durchlauf war die Anzeige im Ausgabefenster nun bedeutend freundlicher:

2>     Bibliothek "D:\Visual C++\Dev\!IntDir\Libraries\CxLibrary\Release_x64\CxLib72.lib" und Objekt "D:\Visual C++\Dev\!IntDir\Libraries\CxLibrary\Release_x64\CxLib72.exp" werden erstellt.
2>  CxLibrary.vcxproj -> D:\Visual C++\Dev\!IntDir\Libraries\CxLibrary\Release_x64\CxLib72.dll
...
3>  sqc.vcxproj -> D:\Visual C++\Dev\!IntDir\SpeedCommander\sqc\Release_x64\sqc.exe
3>  Done Adding Additional Store
3>  Successfully signed: D:\Visual C++\Dev\!IntDir\SpeedCommander\sqc\Release_x64\sqc.exe

Erwähnenswert ist vielleicht noch, dass die Funktion $([System.IO.Path]::GetFullPath(“)) auch in den Befehlszeilen für Buildereignisse verwendet werden kann. Zudem sollte man damit rechnen, dass die Änderungen in Microsoft.cpp.targets beim nächsten VS-Update überschrieben werden können und dann neu durchgeführt werden müssen.

Nachtrag vom 11.05.2015

In der Zwischenzeit hat sich gezeigt, dass das Voranstellen des Projektpfades negative Auswirkungen auf das Neuladen von Projektdateien (z.B. nach dem Zurücknehmen von Änderungen) hat. Ich habe die beiden Zeilen nun so geändert, dass das Projektverzeichnis nur vorangestellt wird, wenn der Pfadname von In/OutDir relativ und nicht absolut ist.

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.

Zeitgleich mit Windows 8.1 hat Microsoft auch die finale Version von Visual Studio 2013 zum Download freigegeben.

Ich werde mir die neue Umgebung sicher mal in einer virtuellen Maschine anschauen. Zum produktiven Einsatz wird es aber nicht reichen. Weitaus interessanter sind da der neue Compiler und die MFC. Ich bin guter Hoffnung, dass sich beide wieder ohne großen Aufwand in Visual Studio 2008 integrieren lassen.