seeseekey.net - Invictus Deus Ex Machina

Statische Codeanalyse ist eine feine Sache. Sie weißt auf Fehler und Probleme schon zur Entwicklungszeit hin. Dafür gibt es unter anderem Systeme wie SonarQube. Wem ein solchen System zu groß ist, der kann SonarLint nutzen, welches statische Codeanalyse lokal in der gewünschten IDE liefert.

sonarlint.org/intellij/

sonarlint.org/intellij/

Für IntelliJ IDEA findet man die passende Version dabei unter sonarlint.org/intellij/. Daneben gibt es auch Versionen für Eclipse und Visual Studio. SonarLint wird dabei mit einem vorgefertigtem Regelsatz geliefert und kann nach der Installation gleich genutzt werden. SonarLint ist unter der GPL in Version 3 (bzw. der LGPL) lizenziert und damit freie Software.

Das Visual Studio formatiert den Quellcode automatisch nach den eingestellten Richtlinien. Wenn man nun aber die Richtlinien ändert, steht man vor dem Problem, das der Quelltext noch nach den alten Richtlinien formatiert ist.

Die Formatierungseinstellungen im Visual Studio

Die Formatierungseinstellungen im Visual Studio

Leider gibt es keine direkte Option im Visual Studio um den bestehenden Quelltext am Stück neu zu formatieren. Allerdings kommt man mit einem kleinen Makro (abgeleitet vom VS Formater Macro) an dieser Stelle weiter. Dazu wird im Visual Studio die Package Manager Console (zu finden unter Tools -> NuGet Package Manager -> Package Manager Console) geöffnet und dort folgendes eingegeben:

function f($projectItems) { $projectItems | ? { $_.Name -ne $null -and $_.Name.EndsWith( ".cs" ) -and -not $_.Name.EndsWith( ".Designer.cs" ) } | % { $win = $_.Open('{7651A701-06E5-11D1-8EBD-00A0C90F26EA}') ; $win.Activate() ; $DTE.ExecuteCommand('Edit.FormatDocument') } ; if ($projectItems) { $projectItems | % { f($_.projectItems) } } }
 
$dte.Solution.Projects | % { f($_.ProjectItems) }

Das Visual Studio öffnet nun alle *.cs Dateien in der geöffneten Solution und formatiert die Quelltexte neu. Dieser Vorgang ist dabei relativ langsam und führt bei größeren Projekten dazu das das Visual Studio einfriert. Auf Stack Overflow gibt es eine elegantere Lösung:

function FormatItems($projectItems) {
    $projectItems |
    % {
        # Write-Host "    Examining item: $($_.Name)";

        if ($_.Name -and $_.Name.ToLower().EndsWith(".cs") `
            -and (-not $_.Name.ToLower().Contains(".designer."))) {

            $win = $_.Open('{7651A701-06E5-11D1-8EBD-00A0C90F26EA}');
            $win.Activate();

            $dte.ExecuteCommand('Edit.FormatDocument');

            if (!$_.Saved) {
                Write-Host "    Saving modified file: $($_.Name)";
                $dte.ExecuteCommand('File.SaveSelectedItems');
            }

            $dte.ExecuteCommand('Window.CloseDocumentWindow');
        }

        if ($_.ProjectItems -and ($_.ProjectItems.Count -gt 0)) {
            # Write-Host "    Opening sub-items of $($_.Name)";

            FormatItems($_.ProjectItems);
        }
    };
}

$dte.Solution.Projects | % {
    Write-Host "-- Project: $($_.Name)";

    FormatItems($_.ProjectItems)
}
;

Bei dieser Lösung wird jede Datei nach der Neuformatierung, gespeichert und wieder geschlossen. Leider wird auch diese Lösung von Datei zu Datei langsamer, so das sie für größere Projekte wiederrum unbrauchbar ist. Mit der Extension Format Document gibt es eine Lösung welche schnell genug ist, allerdings funktioniert diese nur unter Visual Studio 2010. Nach einigen Anpassungen habe ich eine Version gebaut, welche auch unter Visual Studio 2012 und 2013 läuft. Das Problem an dieser Variante ist, das Dateien in Ordnern nur berücksichtigt werden wenn der Ordner im Solution Explorer geöffnet ist. Alles in allem ist keine der vorgestellten Lösungen wirklich optimal, allerdings kann man viele Fälle mit den vorgestellten Lösungen lösen.

Mit dem Visual Studio Addin Resource Refactoring Tool ist es möglich Strings in Ressourcendateien zu übertragen. Dies wird unter anderem für solche Zeichenketten benötigt, welche später übersetzt werden sollen. Leider gibt es auf der offiziellen Seite keine Version für das Visual Studio 2013. Deshalb habe ich mal ein funktionierendes Kompilat gebaut, welcher hier heruntergeladen werden kann. Die Installation ist in der beigelegten Textdatei beschrieben.

Das Resource Refactoring Tool im Visual Studio 2013

Das Resource Refactoring Tool im Visual Studio 2013

Problematisch an dem Resource Refactoring Tool ist das es die Addin-Schnittstelle des Visual Studios nutzt, welche als veraltet gekennzeichnet ist. Unter dem Namen Jinnee.Prelude gibt es mittlerweile eine Extension, welche in der Visual Studio Gallery zu finden ist, und als Alternative betrachtet werden kann. Allerdings läuft sie noch nicht so rund, wie das Resource Refactoring Tool.

Wenn man unter Visual Studio 2013 ein C/C++ Projekt welches MBCS nutzt kompilieren möchte, wird man mit einer Fehlermeldung bedacht:

MSB8031: Building an MFC project for a non-Unicode character set is deprecated. You must change the project property to Unicode or download an additional library.

Der Grund für dieses Problem ist, das der MFC Support für Multibyte Character Sets als veraltet markiert wurde und deshalb nicht mehr mit Visual Studio 2013 mitgeliefert wird. Zur Lösung des Problems kann die Anwendung auf Unicode portiert werden oder eine Zusatzbibliothek von Microsoft installieren.

Die Entwicklung von Controls unter .NET und Windows Form geht eigentlich relativ leicht von der Hand. Kompliziert wird das ganze immer dann wenn Fehler auftreten. So lassen sich Controls welche im Designmodus Exceptions werfen, nur schwer debuggen. Aber wie immer gilt, wo ein Wille ist, da ist auch ein Weg.

Das Attach to Process Fenster

Das Attach to Process Fenster

Um ein Control zu debuggen, sollte man das entsprechende Projekt bzw. die Solution zwei mal öffnen. In dem einen Visual Studio öffnet man nun den Designer. Im anderen Visual Studio wählt man im Debugmenü den Punkt “Attach to Process…” aus. Das sich öffnende Fenster zeigt alle Prozesse an, an welche sich der Debugger anhängen kann. Hier wird das erste Visual Studio (das mit dem Designer) ausgewählt. Nun kann man im Quelltext des Controls Breakpoints setzen und somit die Ausführung überwachen. Allerdings sollte man sich dabei nicht wundern, das dass Control im Debugger größer erscheint als es eigentlich ist. Der Grund dafür liegt darin, das genau genommen nicht das Control sondern das gesamte Visual Studio debuggt wird.

Manchmal ist es nötig je nach Konfiguration ein anderes Assembly in ein .NET/Mono Projekt einzubauen. Direkt im Visual Studio funktioniert das leider nicht. Allerdings kann man die Einstellung mit einem Texteditor in der Projektdatei vornehmen:

<Reference Include="libInterval" Condition="'$(Configuration)'=='Debug'">
  <HintPath>libInterval\x32-debug\libInterval.dll</HintPath>
</Reference>
<Reference Include="libInterval" Condition="'$(Configuration)'=='Release'">
  <HintPath>libInterval\x32-release\libInterval.dll</HintPath>
</Reference>

Wichtig ist dabei der “Condition”-Teil welcher festlegt das die eine DLL nur bei der jeweiligen Konfiguration genutzt wird. Durch diesen landet das richtige Assembly später im entsprechenden Buildordner.

Mit der Installation einer Version des Visual Studios landen eine Menge Tools auf dem Rechner des Benutzers. Eines der Tools welche dabei leider nicht auf der Platte landet, ist der CLR Profiler, welcher auch aus dem Hause Microsoft stammt.

Eine Auswertung des CLR Profilers

Eine Auswertung des CLR Profilers

Mit diesem Tool kann die Innereien seiner .NET Software, wie die Speicherbrauch im Heap, die Handleanforderungen und ähnliches analysieren und auswerten. Heruntergeladen werden kann der CLR Profiler unter http://www.microsoft.com/en-us/download/details.aspx?id=16273.

Wenn man sein Visual Studio hinter eine Proxyserver betreibt, so kann es passieren das die “Online Gallery” nicht funktioniert. Möchte man dies ändern so muss man je nach Visual Studio, eine der folgenden Dateien ändern:

C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config (Visual Studio 2010)
C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe.config (Visual Studio 2012)
Die Online Gallery ist offline

Die “Online Gallery” ist offline

Dort findet man einen Block der in etwa so aussehen sollte:

<system.net>
  <settings>
    <ipv6 enabled="true"/>
  </settings>
</system.net>

Dort fügt man den Tag:

<servicePointManager expect100Continue="false" />

innerhalb des “settings” Tag hinzu. Nach einem Neustart des Visual Studios, sollte auch die “Online Gallery” wieder funktionieren.

Wenn man das Visual Studio 2010 oder 2008 gewöhnt ist, so kommt der erste Start der 2012 Version des Studios einem kleinen Schock gleich. Die Oberfläche sehr kontrastarm und ungewohnt. Auch das Menü wirkt mit seinen groß geschriebenen Einträgen sehr gewöhnungsbedürftig.

Das Visual Studio 2012 nach einigen "Tuning"-Maßnahmen

Das Visual Studio 2012 nach einigen “Tuning”-Maßnahmen

Das Problem mit den Farben bekommt man relativ schnell mit der Erweiterung Visual Studio 2012 Color Theme Editor in den Griff. Diese bietet beim Neustart des Visual Studios die Möglichkeit das Farbschema seinen Bedürfnissen anzupassen.

Dem Menü kommt man nur durch einen beherzten Eingriff in die Registry bei. Hierzu wird im Registrybaum zur Stelle:

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\11.0\General

navigiert und dort ein “DWORD” mit dem Namen “SuppressUppercaseConversion” und dem Wert “1” angelegt. Nach einem Neustart des Studios ist dann auch das Menü wieder normal.

Bei der Entwicklung wundert man sich ab und an, was für interessante Projekte in den Weiten des Netzes so umherschwirren. So unter anderem das Projekt Script#. Dabei handelt es sich um eine Erweiterung für das Visual Studio 2012 mit welcher es möglich ist C# Quelltext (so er gewissen Kriterien genügt) in JavaScript umzuwandeln, bzw. zu compilieren.

Die Erweiterung welche im Quelltext unter https://github.com/nikhilk/scriptsharp zu finden ist, steht dabei unter der Apache Lizenz und ist somit freie Software. Nach der Installation fügt sie dem Visual Studio neue Projekttypen hinzu, mit welchen man anschließend arbeiten kann. Leider gibt es von Script# keine MonoDevelop Variante, so das man im Moment zwingend an das Visual Studio gebunden ist. Allerdings findet sich in der Roadmap folgender Satz:

In terms of code contribution, it would be especially interesting to see the development of import libraries for common libraries, so they are easily usable right out of the box. It would also be interesting to see the development of complementary tools/addins, adding support to other IDEs (esp. MonoDevelop) and other such complementary projects. Or you might be interested in the very core, i.e. the compiler itself.

Also wenn sich jemand bemüßigt fühlt, das ganze für MonoDevelop in Angriff zu nehmen, der muss nun nicht mehr auf die Einladung warten. Die offizielle Projektseite von Script# ist unter http://scriptsharp.com/ zu finden.