.NET und PDF Software

Als ich vor kurzem gefragt wurde, ob ich meinen Test der neuen NDepend Version erneuern möchte, stimmte ich gern zu. Diese Software bezeichnet sich selbst als ein „Schweizer Taschenmesser für .NET und .NET Core Entwicklung Teams“. Es bietet vielfältige Möglichkeiten, um ein Projekt auf Code-technische Probleme und technische Schulden zu untersuchen und das auch über einen zeitlichen Verlauf in grafischer Form darzustellen bzw. die konkreten Veränderungen zu ermitteln.

Die Installation ist einfach und die Integration in Visual Studio ist optional, schnell gemacht und für mich ein echter Mehrwert, da ich bereits während der Entwicklung schnellen Zugriff auf alle relevanten Funktionen habe. Obwohl NDepend dann regelmäßig automatisch Analyseergebnisse sammelt, merkt man davon während der normalen Arbeit in Visual Studio nichts. Das ist bei Visual Studio Erweiterungen anderer Hersteller leider nicht immer der Fall.

Mit einem einfachen Klick auf einen großen Kreis erhält man eine kleine Übersicht, kann eine Analyse von Hand starten oder einfach ins Dashboard wechseln. Dort erhält man eine Einschätzung der Projektqualität. Das basiert auf einem sehr ausgefeilten Regelwerk, welches der Hersteller entwickelt hat. Ich habe das Regelwerk nicht selbst geändert. Ich habe schließlich das Projekt der Code-Analyse wieder aufgegriffen, weil ich das Tool als neutralen und unbestechlichen Auditor meiner Softwareprojekte sehe, der wesentlich mehr Erfahrung als ich in diesem Bereich hat. Die Darstellung des Dashboards beinhaltet eine anpassbare Übersicht. Bestandteil sind einmal Diagramme über die Entwicklung der Kennzahlen. Weiter ist, im Besonderen nach der Auswahl einer Vergleichsbasis, eine Darstellung der Projektbewertung jetzt und im direkten Vergleich zu finden. Das schließt eine nach Schweregrad gruppierte Übersicht der Anzahl der Vorfälle ein. Ein Klick auf diese Zahl bringt ein sofort in eine konkrete Übersicht der Vorfälle bzw. Probleme. Dies ist besonders dann hilfreich, wenn man eine Entwicklung einer Kennzahl vielleicht nicht so erwartet hat und man nun die Ursache ergründen möchte.

Hier beginnt jetzt aber auch der anspruchsvolle Teil! Man kann sehr leicht die einzelnen Vorfälle heraussuchen und bekommt die Fundstellen sogar angezeigt, wenn Sie nur der Vergleichsbasis zu finden waren, nun also entfernt oder korrigiert wurde. Ferner sieht man die Definition des Vorfalls in einer LINQ ähnlichen Sprache, mit einer ausführlichen Erklärung und weiteren externen Verweisen. Die Beschreibungen sind sehr gut, prinzipbedingt aber gerade am Anfang keine leichte Kost! Hier muss man schon einen festen Willen haben, das persönliche Niveau zu verbessern. Keine Verständnisprobleme bei englischen Texten sind auch hilfreich. Dann findet man in NDepend jedoch einen idealen Partner.

Ein Prunkstück, auf das der Hersteller besonders stolz ist, ist der Dependency Graph. Der Name ist Programm! Grenzen scheint es für dieses Modul nicht wirklich zu geben. Man kann mit einer sehr hohen Geschwindigkeit das Zusammenspiel der eigenen oder externen Klassen, Namensbereichen oder Funktionen anschauen und durch viele, oft sehr sinnvoll vorbelegte Optionen, übersichtlich gestalten. Das kann sehr hilfreich bei der Sichtung oder Umgestaltung von Codebereichen sein. Die Leistungsklasse wird eindrucksvoll durch die Präsentation der .NET Core 3 Klassen gezeigt. In meinen eigenen aktuellen Projekten ist mir die Struktur jedoch extrem vertraut. Darum ist steht bei mir das Modul nur in der zweiten Reihe, für viele andere Entwickler wird das sicher nicht gelten.

Kommen wir noch zur Einschätzung des Preises. Dieser liegt ungefähr im Bereich der JetBrains-Tools. Da der Kundenkreis merklich kleiner sein wird, ist das bezogen auf den Funktionsumfang mehr als fair. Positive muss hier erwähnt werden, dass NDepend einer permanenten Entwicklung unterliegt und man trotzdem nicht den Eindruck bekommt, dass die Fertigstellung erst beim Kunden geschieht. Das obligatorische Subscription-Model ist damit gerechtfertigt. Im Vergleich zu meinen älteren Versionen empfinde ich beispielsweise die Integration innerhalb Visual Studio wesentlich umfangreicher und runder.

Fazit: Vermisst habe ich lediglich die Kombination der Analyse mit einer Versionsverwaltung wie SVN oder Git. Das ist schade und stellt sicher noch ein großes Potential für die Zukunft dar. Mein persönliches Highlight von NDepend bleibt ganz klar die große Menge an vordefinierten Regeln. Diese sind sauber definiert, gut gruppiert, flexibel anpassbar und vor allen Dingen gut mit den passenden Hilfethemen verbunden.

Vor gut 3 Jahren habe ich hier eine Bewertung von NDepend veröffentlicht. Nun ist vor kurzem der Hinweis auf eine größere Aktualisierung eingetroffen. Diese neue Version habe ich wieder unter die Lupe genommen und in aktuellen Projekten mit Visual Studio 2015 getestet. Für alle Programmierer, welche dieses Tool nicht kennen:

NDepend ist eine Software, mit der die Softwarequalität eines .NET-Programms überprüft werden kann. Für die Überprüfung und Auswertung stehen sehr viele Möglichkeiten zur Verfügung. Durch historische Betrachtungsmöglichkeiten kann ebenfalls eine zeitliche Entwicklung der Qualität geprüft und sichergestellt werden.

Die Installation war vertraut, es ist ein wenig Handarbeit angesagt, die einen Software-Entwickler in keinster Weise vor Fragen stellt. Danach ist das PlugIn in Visual Studio einsatzbereit oder mal kann eine lokale Version nutzen. Jetbrains Resharper beispielsweise nimmt einem bei der Installation etwas mehr Arbeit ab, wirklich schneller ist man aber damit aber nicht fertig. NDepend legt eigene Projektdateien zu einem Visual Studio Projekt an. Damit ändert sich am eigentlich Projekt nichts und Entwickler ohne NDepend und auch die Versionsverwaltung werden nicht beeinflusst. Das gibt einen großen Pluspunkt von mir!

Im den letzten 3 Jahren haben die Entwickler gute Arbeit geleistet. Es wird nun automatisch per Default eine Historie aufgebaut, für Vergleiche herangezogen und auch bei den Auswertungen entsprechend dargestellt. So hat man quasi immer gleichzeitig die Übersicht über alle gefundenen Probleme, kann aber auch erst mal nur die aktuell hinzugekommenen Probleme ansehen. Hier sind viele Einstellmöglichkeiten vorhanden. Ein großer Pluspunkt ist die unglaubliche Anzahl von sinnvollen Optionen, aber zeitweise auch ein Minuspunkt -> man muss erst einmal den Überblick gewinnen und behalten. Auf einem Rechner mit einem normalen Monitor macht das keinen Spaß. Eine Dualscreen-Konfiguration in 4k war hierfür wesentlich effizienter nutzbar.

Ich habe NDepend mit Projekte im WinForm, Asp.Net Webform und Asp.Net MVC Bereich ausprobiert. Hier gab es viele sinnvolle Warnungen und Fehler, die im geprüften Quellcode korrigiert werden sollten. Bei Asp.Net mit WebForms wurden aber auch die Zusammenhänge zwischen Aspx-Formular und Code nicht erkannt, was in sehr vielen Fehlern resultierte, die nicht korrigiert werden können. Hier wird der Hersteller sein Regelwerk noch prüfen.

Apropos Regeln: Es ist eine klare Ausrichtung auf den professionellen Entwickler mit einem Sinn für guten wartbaren Code erkennbar. Alle vordefinierten Regeln sind gut erklärt und über eine interne Linq-ähnliche Sprache anpassbar.

Wie viele Softwarefirmen haben auch die Macher von NDepend ihr Lizenzmodell auf eine Jahresgebühr gestellt. Das ist nachvollziehbar, da ein Produkt wie NDepend eigentlich permanent weiterentwickelt und aktualisiert werden muss, um mit Visual Studio und neuen Funktionalitäten eingesetzt zu werden. Ob der Preise zu hoch oder tief ist, sollte jeder für sich entscheiden. Wer die Softwarequalität seines Teams im Auge behalten will, wir aber sicher nicht an den Kosten scheitern.

Wenn man LINQ-Abfragen etwas dynamischer zusammen bauen möchte, sehnt man sich schnell nach den alten SQL Strings zurück. Das war völlig flexibel, aber auch fehleranfällig. Ein von mir abonnierter Blog hat das Thema aufgegriffen und eine kleine Lösung dafür vorgestellt: Klick hier.

Allerdings fand ich das Vorgehen mit Expressions sehr kompliziert, zumindest für diesen Sachverhalt. Ich habe darum das Beispiel einmal auf meine Herangehensweise umgebaut:

private static void Main(string[] args)
{
    var people = new List<Person>()
    {
        new Person()
        {
            Firstname = "Carl",
            Lastname = "Sample"
        },
        new Person()
        {
            Firstname = "Mark",
            Lastname = "Schulz"
        }
    };
 
    var filtered = people.AsQueryable();
 
    var queryFirstnames = true;
    var queryLastnames = true;
    var searchValue = "l";
 
    if (queryFirstnames)
    {
        filtered = filtered.Where(p => p.Firstname.Contains(searchValue));
    }
    if (queryLastnames)
    {
        filtered = filtered.Where(p => p.Lastname.Contains(searchValue));
    }
 
    Console.WriteLine(filtered.Count());
    Console.ReadKey();
}

Da die Abfrage von LINQ erst so spät als möglich ausgeführt wird, können auch mehrere Bedingungen hintereinander gehängt werden, oder eben auch nicht. Dadurch entsteht automatisch eine AND Verknüpfung. Möchte man eine OR Verknüpfung, so leidet die Lesbarkeit etwas, da man dann mit LINQ Union arbeiten muss.

Nachteil meiner Lösung ist aber, dass man den Zugriff auf die Daten und den Zusammenbau der Abfrage zusammen codieren muss. Sofern das kein Problem darstellt, finde ich diesen Weg etwas übersichtlicher.

Neulich wurde ich mit der Definition einer besonders umfangreichen Aufzählung konfrontiert. Da hierfür die magische 32Bit Grenze überschritten wurde, war ich skeptisch. Ein Test ergab, das diese Skepsis in der Tat berechtigt war. Folgende Deklaration:

public enum Big
{
    Small = 1 << 1,
    Medium = 1 << 8,
    Large = 1 << 40
}

erzeugt dann das Problem. Bis hier:

var enumTest = Big.Small;
Debug.Assert(enumTest == Big.Small);
enumTest = Big.Medium;
Debug.Assert(enumTest == Big.Medium);
enumTest = Big.Large;
Debug.Assert(enumTest == Big.Large);

erscheint alles in Orndung, ein Ausgabetest:

var enumTest = Big.Small;
Console.WriteLine(enumTest);
enumTest = Big.Medium;
Console.WriteLine(enumTest);
enumTest = Big.Large;
Console.WriteLine(enumTest);

zeigt aber dann das Problem. Die Definition Medium und Large sind intern identisch:

Small
Medium
Medium

Zur Lösung des Problems muss man zwei Änderungen durchführen. Einmal ist der Aufzählungstyp von long abzuleiten und die Basiszahl für die Bitverschiebung muss ebenfalls eine long-Zahl sein:

public enum Big: long
{
    Small = 1L << 1,
    Medium = 1L << 8,
    Large = 1L << 40
}

Das Ergebnis bestätigt die korrekte Ausführung. Bei der Nutzung von 64 Bit ist aber dann vorerst wirklich Schluss!

Als ich vor kurzem gebeten wurde, mir NDepend anzuschauen, sagte ich sofort zu. Diese Software versprach mir Unterstützung in der Entwicklung und Überwachung von sauberem Code, ganz im Sinne von CCD. Nach dieser Sichtung habe ich verstanden, dass die Autoren der Software eine großartige Arbeit geleistet haben. Man erhält ein ungeheuer ausgefeiltes Stück Software, das den Entwickler zu Anfang mit der Fülle und dem Umfang von Dialogen und Optionen schlicht überfährt. Man lernt aber schnell, dass es scheinbar unvermeidbar war, damit die Software in unterschiedlichen Bedingungen eingesetzt werden kann. Ich rate jedem, der seinen NET-Sourcecode verbessern möchte oder im Team Fehlentwicklungen im Auge behalten will, sich die Zeit der Einarbeitung zu nehmen. Es lohnt sich!

Überprüfung des eigenen Codes

Als Einstieg sollte man sich diese Seite anschauen: GettingStarted. Dort wird als Video und alternativ in einer reich bebilderte Anleitung dargestellt, wie leicht NDepend mit dem eigenen Projektmappen verbunden werden kann. Dieser Vorgang funktioniert sehr gut und schnell. Die Original-VS-Projekte werden nicht angefasst, die NDepend-Verknüpfung kann auch leicht wieder gelöst werden. Eine SVN-Integration wird dadurch nicht beeinträchtigt.

Dann kann man sich bereits mittels des über das NDepend-Menü erreichbaren DashBoards einen Überblick verschaffen. Diese Beispielgrafik von NDepend stellt natürlich einen späteren Stand dar, zeigt aber die Fülle Informationen: Für mich war besonders wichtig, dass man sogar einen Überblick erhält, ob im Lauf der Zeit immer mehr Regeln verletzt wurden. Das hilft in der Team-Kontrolle! Weiterhin kann aus diesem DashBoard heraus leicht geprüft werden, welche Regeln verletzt wurden und vor allen Dingen: an welcher Stelle im Source! Regeln, welche man nicht für wichtig erachtet, kann man leicht deaktivieren. Alle Regeln liegen auch in einer gut kommentierten LINQ-ähnlichen Sprache vor, was die Anpassung leicht macht. Hier steht zusätzlich zu jeder NDepend eigenen Funktion eine gute Hilfe im Maus-Tooltip zur Verfügung.

Vergleichen der Entwicklungsgeschichte

Man stellt schnell fest, dass es nicht immer sinnvoll und praktikabel ist, gleich den kompletten Code Regelkonform zu gestalten, sprich alle Regel-Verletzungen zu entfernen. NDepend bietet hier die Möglichkeit, Basisstände als Vergleich heranzuziehen. Somit werden nur noch neuere Regelverletzungen angezeigt, was natürlich gerade für den Start sinnvoll ist. Als Start kann man dazu, wie in der nebenstehenden Grafik dargestellt, die historische Speicherung der Werte auf Always stellen. Damit hat man bereits nach der ersten NDepend-Überprüfung einen Vergleichsstand zur Verfügung, was den Start stark erleichtert.

Bewertung
NDepend eignet sich nicht für den Programmiereinsteiger. Man muss ein Interesse an Clean Code haben und auch schon diverse Regeln kennen und anwenden, LINQ darf kein Fremdwort mehr sein. Dann bietet NDepend eine sehr gute Untersützung. Wenn man für diesen Schritt bereit ist, bietet das Tool einen hervorragenden Start in die permanenten Prüfung und Überwachung von Code-Regeln, zumal sogar für die Integration in Buildserver gesorgt wurde. NDepend liefert ein umfangreiches Set an Regeln, sauber gruppiert, bereits mit. Eigene Regeln können aus dem Code extrahiert werden. Als absolutes Power-Feature bewerte ich die Definition einer Baseline für vergleichende Berichte. Damit können alte Probleme leichter ausgeblendet werden.

Eine Bewertung zum Preis fällt schwer: Die Dialog von NDepend wurden mit sehr viel Liebe erstellt. Praktisch überall stehen sinnvolle Optionen, Verknüpfungen zu Hilfethemen und Tooltips zur Verfügung. Der Preis erscheint hierfür eigentlich zu gering. Aus der Sicht der Programmierer, die bei Clean-Code oft nicht gerade offene Türen einrennen, ist der Preis dann wieder wirklich sinnvoll und mit Blick auf den Funktionsumfang mehr als fair.

Beim Öffnen großer Formulare in Visual Studio Formular Designer (WinForms) tritt teilweise das Problem auf, dass Visual Studio 2012/2013 wegen eines Problems beendet wird. In der Ereignisanzeige wird dabei ein Problem in der KERNELBASE.dll vermerkt.

Die Lösung ist dann eigentlich trivial: Es muss der Dienst Performance Logs & Alerts (pla) gestartet werden.

Es besteht nun die Vermutung, dass der Formulardesigner einfach eine Performance-Warnung melden wollte und das nicht konnte, weil der Dienst nicht aktiv war.

Vor kurzem wurde ich von einer Anfrage eines Kunden überrascht. Eingaben auf meiner MVC Seite nach einer längeren Wartepause, die durchaus im Bereich von Stunden liegen kann, führten wieder zum Login. Da wir keine Daten in Sessions gespeichert haben, konnte ich mir das Verhalten erst nicht erklären. Ich bin immer davon ausgegangen, dass ein POST alle notwendigen Daten überträgt. Bei den Login-Informationen passte hier wohl etwas nicht wie erwartet. Also habe ich das ganze analysiert:

Bei einer MVC 3 oder 4 Webseite mit Formular-Authentifizierung wird folgender Code zum Setzen der Authentifizierungsinformationen aufgerufen:

FormsAuthentication.SetAuthCookie(model.UserName, model.RememberMe);

Wählt der Anwender nun die Option Speichern nicht aus, so wird beim Authentifizierungscookie automatisch die Verfallsinformation auf Session gesetzt. Da Sessions in der Standardeinstellung nach 20 Minuten Inaktivität verfallen, erklärt es auch, warum nach längerer Pause die Anmeldung ungültig wurde:

FormsAuthentication.SetAuthCookie(model.UserName, false);

Besser sieht es jedoch auch, wenn die Anmeldeinformationen gespeichert werden dürfen:

FormsAuthentication.SetAuthCookie(model.UserName, true);

Dann wird das Authentifizierungscookie automatisch mit dem Verfallsdatum des Timeouts der Web.config gesetzt, hier 2880 Minuten => 2 Tage.

  <system.web>
    <authentication mode="Forms">
      <forms loginUrl="~/Account/Login" timeout="2880" />
    </authentication>
  </system.web>

Mir persönlich fehlt jetzt noch die Option, dass Authentifizierungscookie bis zum Ende der Browsersitzung behalten zu können, aber man kann scheinbar nicht alles haben.

Eigentlich leide ich zur Zeit unter notorischem Zeitmangel. Aber das .NET Open Space in Karlsruhe habe ich mir dieses Jahr nicht nehmen lassen. Nachdem ich letztes Jahr nicht teilnehmen konnte, war es für mich der zweite Besuch. Viele Gesichter kannte ich aus diesem Grund schon. Die Veranstaltung wurde wieder in den Räumen von bluehands ausgerichtet. Ich finde das nach wie vor beachtlich, alles einfach mal so umzuräumen. Danke!
Die Themen wurden von den 70 Teilnehmern wieder selbst bestimmt und wie auch schon 2010 war es kein Problem, ausreichend Themen für die Agenda zu finden. Neuer großer Schwerpunkt war ganz klar die Entwicklung für Smartphones. Kaum einer kann sich der Problematik momentan entziehen und irgendwo ist mit dem Windows 8 Tablet ja auch von Microsoft etwas im Anmarsch, was deren Windows Phone pushen könnte. Interessant war in diesem Fall die aktuelle Dominanz von Apple-Hardware, zeitweise waren auf dem Openspace 80% der Notebooks und Tablets von Apple. Auf alle Fälle durften wir diesbezüglich einen guten Einblick in die Entwicklung für Android und Apple-Smartphones mit Xamarin gewinnen.
Christina Hirth griff das Thema CleanCode(Developer) auf, was eine sehr intensive Diskussion in Gang brachte. Es herschte eine Einigkeit darüber, dass den meisten Teilnehmer vom #nossued das Thema wohl geläufig ist. Eine gute Möglichkeit, dieses in Firmen einzubringen, könnten Coding Dojos sein.

Im Microsoft .NET Framework ist schon lange eine Funktion zum Kürzen von Dateinamen enthalten. Aus c:\Windows\System32\MyDll.dll kann dann zum Beispiel c:\Windows\…\MyDll.dll werden. Hierzu greift man auf TextRenderer.MeasureText zurück. Allerding hat diese Funktion einen kleinen Fehler bei dem zurückgegebenen Wert, der hier beschrieben ist:

Der Workaround ist zum Glück auch gleich angegeben, und kann dann so aussehen:

string filename = string.Copy(filenameForOutput);
if (!string.IsNullOrEmpty(filename))
{   
   TextRenderer.MeasureText(filename, Font, Size,
     TextFormatFlags.PathEllipsis | TextFormatFlags.ModifyString);
   filename = filename.Substring(0, filename.IndexOf('\0'));
}

Der Source zeigt auch gleich noch eine kleine andere Ergänzung: Die Funktion modifiziert den übergebenen String. Man sollte diesen also vorher kopieren, sofern man nicht schon mit einer Kopie des Strings arbeitet.

Glaubt man der Dokumentation von HttpRequest.ApplicationPath, so ist es recht einfach, einen Link in einer eigenen Asp.NET Seite zu verwenden:

Label1.Text = Request.ApplicationPath;
Image1.ImageUrl = Request.ApplicationPath + "/images/Image1.gif";
Label2.Text = Image1.ImageUrl;

Aber damit steht man schnell vor einem Problem: Liegt die Anwendung im Root, wie es beispielsweise standardmäßig beim Visual Studio 2010 Development Server der Fall ist, so erhält man als Ergebnis nur ein /. Die korrekte Zeile wäre dann also:

Image1.ImageUrl = Request.ApplicationPath + "images/Image1.gif";

Befindet sich die Seite aber in einem virtuellen Verzeichnis, so kommt das Verzeichnis ohne abschließenden / zurück:

Image1.ImageUrl = Request.ApplicationPath + "/images/Image1.gif";

Je nach Speicherort muss man also beim händischen Zusammensetzen der URL’s also den abschließenden Slash berücksichtigen, oder eben auch nicht.

Eine gute Lösung habe ich in einem Blog-Artikel von 2004 gefunden:

VirtualPathUtility.ToAbsolute("~/images/Image1.gif")

Damit überlässt man Asp.NET die korrekte Umsetzung, welche auch tadellos und ohne Experimente funktioniert!

Update:
Manchmal sieht man einfach den Wald vor lauter Bäumen nicht. Die kürzere Lösung ist Url.Content, welche ein vergleichbares Ergebnis liefert und auch in den Templates von Asp.NET MVC3 verwendet wird.