Zur Installation genügt auf dem auf Debian basierenden Raspbian der Aufruf des Paketmanagers auf der Konsole:

sudo apt-get install mono-complete

Nachdem nun die eigene .Net App auf den Raspy kopiert wurde lässt sie sich einfach starten:

mono APP-NAME.exe

Grundsätzlich funktioniert die Installation auch über:

sudo apt-get install mono

Dies produziert dann beim Start  einer eigenen App eine Menge Assembly Not Found Exceptions.

Extension Methods wurden mit .Net 3.5 eingeführt und erlauben es einen Type zu erweitern ohne von ihm abzuleiten. So können bequem sogar „sealed“ Types wie System.String erweitert werden – z.B. um eigene Substring Funktionen. Eine ebenfalls sehr nützliche Funktionalität ist es (generische) Interfaces mit konkretem Code zu hinterlegen, ohne alle Ableitungen des Interfaces zu überarbeiten zu müssen. Eine Extension Method zu IList erweitert also sofort alle Klassen die darauf aufbauen.

Das alles macht im ersten Moment den Eindruck einer Mehrfachvererbung. Das suggeriert auch Visual Studio, indem es die Extension- mit den Instanz-Methoden zusammen anzeigt:In Wirklichkeit handelt es sich aber nur um „Syntax Sugar„, also einer reinen Vereinfachung für den Programmierer – intern sind das verschiedene Klassen.

Das hat mehrere Konsequenzen:

• Extension Methods können keine Interfaces implementieren
• sie können keine abstracten Methoden ausprogrammieren
• per Reflection sind Extensions nicht in der eigentlichen Klasse zu finden

Der Versuch die Extension auf normalem Wege per Reflection zu finden scheitert:

MethodInfo method = typeof(MyClass)
   .GetType()
   .GetMethod("ExtensionMethod");
Assert.IsNotNull(method); //Dieser Test wird scheitern

Die gesuchte Methode ist eben nicht im gleichen Typ definiert, sondern in einer beliebigen anderen Klasse.

Um alle Extension Methods zu einer bestimmten Klasse zu finden, ist es notwendig alle Typen der Assembly (oder AppDomain) nach Methoden zu durchsieben die zum gesuchten Type („TypeToSearchFor“) erfüllen:

var methods = TypeToSearchFor.Assembly
  .GetTypes()
  .Where(t =>
       t.CustomAttributes
       .where(a => a.AttributeType == typeof(ExtensionAttribute))
       .Count() == 1
       )
  .SelectMany(t => t.GetMethods())
  .Where(m=>m.IsStatic == true)
  .Where(m => m.GetParameters().Count() != 0)
  .Where(m => m.GetParameters()[0].ParameterType == TypeToSearchFor)
  ;

Als Anhang befindet sich ein Testprojekt mit :

• BeispielKlasse und Extension dazu
• TestProjekt mit Reflection zum Suchen der Methoden
• ReflectionHelper Klasse zum Suchen aller Extension Methods

Ein Ansatz um den Code in Zahlen zu fassen sind Code Metriken… Visual Studio 2010 Team Foundation Edition hat das bereits integriert und liefert auf Knopfdruck eine Auswertung aller bestehenden Klassen und Methoden.

• Maintainability Index
• Cyclomatic Complexity
• Depth of Inheritance
• ClassCoupling
• Lines of Code

Aber was hat das nun zur Aussage ?

Von hinten angefangen:

Lines of Code
Das ist wohl das am leichtesten zu verstehende Metrik, und bezeichnet schlicht und ergreifend die Anzahl der Zeilen pro Klasse. Wer hier Klassen findet, die jenseits der 1.000 (oder 10.000 !!??) oder Methoden die jenseits der 100 Zeilen gefunden hat, ist vom Hot Spot des Codes nicht weit entfernt.

Class Coupling
Bezeichnet die Anzahl der Klassen die von dieser Klasse oder Methode referenziert werden. Um so mehr Klassen benutzt werden, um so komplizierter der (Unit-) Test , um so schwerer die Wiederverwendung. Gibt es wenige Objekte die quasi alle anderen Klassen referenzieren ist dies die Implementierung eines God-Object-Antipatterns.

Depth of Inheritance
Auch hier gilt, um so mehr Ableitungen, um so schwerer ist es für jemand aussenstehenden sich einzuarbeiten. Mit dieser Metrik konnte ich bisher am wenigstens anfangen, da viele Objekte z.B. für die Peristierung relativ unkritische Basisklassen besitzen.

Cyclomatic Complexity
Salop formuliert, wird bei dieser Metrik die Anzahl der Kontrollstrukturen (if, switch…) gezählt. Je höher desto schlechter.
Auf die Klasse gesehen ist die Aussagekraft meiner Meinung nach nicht hoch, für die einzelne Methode allerdings um so mehr! Eine Methode mit vielen komplexen, verschachtelten If-Statements macht die Einarbeitung nicht leichter. Gerne wird dieser Code auch mit Antipattern wie Magic Strings kombiniert.
Diese Problematik lässt sich i.d.R. durch bessere Strukturierung des Codes und Objektorientierung vermeiden.

Maintainability Index
… ist sozusagen das Aggregat aus allen anderen Metriken. Je niedriger desto schlechter.
Visual Studio markiert alles unter 30 als rot. Meiner Erfahrung nach ist die Grenze des Guten schon bei unter 50 erreicht und ein Blick in den Code ist notwendig.

Erfahren Sie hier mehr darüber !

Ich freue mich über Ihr Feedback!

public class Person
{
public int ID { get; set; }
public string Vorname { get; set; }
public string Nachname { get; set; }
}

Das Sortieren nach Nachnamen ist noch einfach:

List<Person> personen = new List<Person>();
//.......Laden der Liste

personen.OrderBy(p => p.Nachname);

Aber was, wenn zwei Personen den gleichen Nachnamen haben?

personen.OrderBy(p => p.Nachname).OrderBy(p => p.Vorname);

Das ist nicht die Lösung. Die Liste wird nun nur noch nach Vorname sortiert.

Die Lösung ist die Extension „ThenBy“, damit wird nun innerhalb eines Nachnamens nach Vornamen sortiert – wie gewünscht!

personen.OrderBy(p => p.Nachname).ThenBy(p => p.Vorname);

Ich persöhnlich sortiere zum Schluss gerne noch nach etwas syntetischem – beispielsweise der ID.
Das hat den Vorteil, dass selbst im unmöglichsten Fall (in diesem Beispiel, dass zwei den gleichen Vor- und Nachnamen haben) immer eine definierte Reihenfolge festgelegt ist. Selbst in diesem Fall, erhält der User in der Oberfläche immer eine definierte Reihenfolge. Gerade bei PLinq kann man sich ja auf die Reihenfolge gar nicht mehr verlassen..

personen.OrderBy(p => p.Nachname).ThenBy(p => p.Vorname).ThenBy(p=>p.ID);

Diese bietet in ASP.Net Seiten ähnlich dem Application oder Session Object die Möglichkeit Werte/Objekte zu speichern, ist hier aber intelligenter und verwirft die Objekte nach einer festgelegten Zeitdauer. Die Intellisense Hilfe zu den Methoden ist selbsterklärend: Ablauf nach einer Zeitspanne, nach einem absolutem Datum …

Selbsterklärend ? Dachte ich…  Bei der Verwendung erhielt ich beim ersten Zugriff auf Cache aus einer aspx-CodeBehind-Klasse heraus eine HTTPException mit der Meldung „Cache is not available“ bzw „Cache ist nicht verfügbar“.  Lange habe ich nach der Lösung gesucht; vielleicht muss man den Cache ja irgendwo (web.config, Page Directive etc) aktivieren?! Aber nichts. Auch Google stellt sich dumm.

Letztenendes ist die Lösung einfach statt nur „Cache.Get(…“  „HttpContext.Current.Cache…“ zu verwenden. Leider habe ich keine Erklärung parat woran es liegt ?!

Auf der Suche nach Erklärungen habe ich mich nun selber auch mal mit der Performance von alltäglichen Code beschäftigt. Wie wäre es z.B. mit String Operationen ? Da gibt es doch immer das Gerücht, das die Verbindung von Strings über „+“ viel zu langsam ist. Damit fange ich doch gleich mal an….Also schnell mal den Code hier hingepinselt (Code1) und auch gleich die Verbesserung dazu (Code2).

//Code1
Stopwatch watch = Stopwatch.StartNew();
string res = "abc" + "abc123";
watch.Stop();

//Code2
Stopwatch watch = Stopwatch.StartNew();
string res = String.Concat("abc" + "abc123");
watch.Stop();

Die Klasse Stopwatch zeigt, wie der Name schon sagt, die vertrichene Zeit an. Mit etwas Code drum rum zum Aufwärmen und Mitteln der Ausführungszeiten komme ich zu dem Schluss, dass beide 0 Millisekunden brauchen. Ein unbefriedigendes Ergebnis. Also die Messung umgestellt auf Ticks. Das Ergebnis ist, dass mit jeder Wiederholung die Ergebnisse etwas variieren, zwischen 1 und 4 Ticks. Das ist kein Unterschied…  Was ist da also los ? Was macht .Net hier wirklich ?

Um das weiter zu analysieren gibt es Profiler. Es gibt diverse Kaufprodukte (z.B. Redgate Performance und Memory Profiler ), aber auch Microsoft bietet gut versteckt einen Memory Profiler an.  Unter dem Link gibt es den CLRProfiler für  .Net 4 direkt von Microsoft. Man startet über den Profiler sein eigenes Programm und kann auswerten was das eigene Programm so treibt.

32bit Profiler starten, „Start Application“, Pfad auswählen und Programm ausführen lassen. Nachdem es ausgeführt wurde, Klick auf View, Call Graph.

Das Erste was man sieht sind Unmengen von Aufrufen, die mit dem eigenen Programm nichts zu tun haben  – damit verbrät also .Net schon für ein einfaches Consolenprogramm mehrere MB…

Wenn man die Ansicht etwas einschränkt kommt folgendes Ergebnis für meine beiden Möglichkeiten heraus:

Zu sehen ist eine zusammengestellte, gefilterte Ansicht der beiden relevanten Methoden. Der übersichtlichkeit halber Methode2 vor Methode 1.

Was ist da zu sehen ? Die Methode StringConcat2 führt  –  wie auch im Code zu sehen  – String.Concat aus. Aber was ist da bei StringConcat1 passiert ? Da findet sich auch ein String.Concat Aufruf darin! Den Aufruf der Klasse Datetime habe ich selber noch eingefügt, um überhaupt einen Aufruf bei der zweiten Methode zu sehen. Anscheinend hat .Net meine sinnlose Verbindung von nichtssagenden Strings ebenfalls für sinnlos befunden und gleich mal wegoptimiert. Erst durch das Hinzufügen eines „+ Datetime.Now.ToString()“ habe ich quasi volle Überzeugungsarbeit geleistet, sodass der Profiler auch etwas anzuzeigen hatte …

Folgerungen:

• Das .Net-Runtime-Environment überarbeite den Code in nicht unerheblichem Maße
• Die Diskussion um die bessere Variante derart einfacher, einzeiliger Stringverkettungen ist denkbar unsinnig.