Mono-Probleme auf dem Raspberry Pi

Auf einem meiner Raspberry Pi-Rechner läuft eine in Mono geschriebene Server-Applikation. Damit die Server-Applikation funktionierte benötigte sie natürlich die Mono Runtime. Diese kann unter Raspbian einfach mittels des Kommandos:

apt-get install mono-runtime

installiert werden. Als ich die Serverapplikation nach der Installation von Mono ausführen wollte erhielt ich allerdings folgende Fehlermeldung:

Missing method .ctor in assembly Melinda.dll, type System.Runtime.CompilerServices.ExtensionAttribute
Can't find custom attr constructor image: Melinda.dll mtoken ...

Dieses Problem ließ sich durch die Installation der Bibliothek libmono-system-core4.0-cil beheben:

apt-get install libmono-system-core4.0-cil

Im Anschluss erhielt ich bei einem erneuten Startversuch eine weitere Fehlermeldung:

Grapevine.Exceptions.Server.UnableToStartHostException occurred
An error occured when trying to start the Grapevine.Server.RestServer

In diesem Fall kam die Fehlermeldung vom REST-API Framework Grapevine. Allerdings war der Fehler nicht wirklich in der Bibliothek zu finden. Stück für Stück kamen weitere Fehlermeldungen wie diese:

System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.

zustande. Nach einiger Recherche war klar: auch in diesem Fall fehlten weitere Abhängigkeiten aus dem Mono-Framework. In diesem Fall half die Holzhammermethode; die Installation des kompletten Mono-Frameworks. Dazu wurde das Paket mono-complete mittels:

apt-get install mono-complete

installiert. Dieses nimmt ein paar mehr Megabyte als das Runtime-Paket in Anspruch, allerdings sind damit alle möglichen Abhängigkeiten installiert. Somit kann man sich auf die eigentliche Entwicklung und Ausführung der eigenen Applikationen konzentrieren, anstatt einer kuriosen Fehlermeldung nach der anderen hinter her zu jagen.

REST-Server mit Grapevine aufsetzen

In den letzten Tagen habe ich für ein Projekt einen REST-Server geschrieben. Der Server läuft unter .NET bzw. Mono – also war ich auf der Suche nach einer passenden Bibliothek bzw. einem Framework, welches mich bei dem Aufsetzen eines solchen Servers unterstützt. Nach einem Blick auf Nancy und einigen anderen Frameworks bin ich schlussendlich bei Grapevine gelandet.

sukona.github.io

sukona.github.io

Dabei handelt es sich um eine Bibliothek, welche neben einem REST-Client auch einen REST-Server bereitstellt. Das Hauptaugenmerk der Entwicklung wird dabei auf den REST-Server gelegt. Mit Hilfe des Frameworks lässt sich ein REST-Server mittels weniger Zeilen Quellcode aufsetzen:

ServerSettings settings = new ServerSettings();
settings.Host = "localhost";
settings.Port = "1111";

RestServer server = new RestServer(settings);
server.Start();

In diesem Beispiel werden die Einstellungen für den Server angelegt und anschließend dem Server übergeben. Danach wird der Server mit der Methode Start hochgefahren. Damit verfügt man zwar über einen REST-Server, dieser verfügt allerdings über keinerlei Methoden was die praktische Verwendung eher erschwert. Ressourcen für den Server werden mittels des Attributes RestResource markiert:

[RestResource(BasePath = "/time/")]
public class TimeModule
{
    [RestRoute(PathInfo = "date")]
    public IHttpContext GetDate(IHttpContext context)
    {
        context.Response.SendResponse(Grapevine.Util.HttpStatusCode.Accepted, getDate());
        return context;
    }
}

Über das Attribut RestRoute wird eine Methode für Grapevine gekennzeichnet – das Pathinfo definiert dabei den Pfad über welchen diese aufgerufen werden kann. Durch den über das Attribut RestResource festgelegten BasePath lautet die vollständige URL für die Ressource:

http://localhost:1111/time/date

Wird diese Methode per GET aufgerufen, so wird das aktuelle Datum zurückgegeben. Damit ist ein minimaler REST-Server mit einer Ressource implementiert. Grapevine selbst ist unter der Apache Lizenz lizenziert und damit freie Software. Der Quelltext der Bibliothek befindet sich auf GitHub.

Probleme mit dem Xamarin Studio und abgelaufenen Triallizenzen

Vor einiger Zeit hatte ich die Xamarin.iOS-Trial-Lizenz des Xamarin Studio ausprobiert. Als diese abgelaufen war, fragte mich das Xamarin Studio ob ich die Lizenz verlängern oder mit der Starter-Edition fortfahren möchte. Ich entschied mich für die Starter-Edtion. Allerdings gibt es ein Problem. Xamarin Studio fragt nun bei jedem Start nach der gewünschten Option – was nicht nur nervig ist, sondern auch ein Fehler im Studio darstellt.

Das Lizenz-Pop-Up

Das Lizenz-Pop-Up

Als schnellen Workaaround kann der Account vom Xamarin Studio getrennt werden, allerdings ist das nicht die optimale Lösung. Stattdessen sollte man den Support kontaktieren und die Trial-Version aus dem Account entfernen lassen. Danach gehört das Problem der Vergangenheit an.

Quellcodeformatierung unter Xamarin Studio

Unter Xamarin Studio ist es wie in vielen IDEs möglich den Quelltext automatisch zu formatieren. Allerdings unterscheidet sich das Konzept etwas, von anderen C#/.NET IDEs wie dem Visual Studio. Xamarin Studio kennt hierbei einmal Benutzerrichtlinien und normale Einstellungen. In den Einstellungen kann die Codeformatierung für den entsprechenden Nutzer angelegt und modifiziert werden.

Die Einstellungen im Xamarin-Studio

Die Einstellungen im Xamarin Studio

Möchte man bestimmte Einstellungen allerdings auf mehreren Rechnern nutzen, so sollte man lieber eine Benutzerrichtlinie anlegen. Wenn die passenden Einstellungen in der Benutzerrichtlinie definiert sind, können sie auch als Datei exportiert und auf dem anderen Rechner importiert werden. Damit die Nutzerrichtlinie Wirkung zeigt, muss sie in den Einstellungen ausgewählt werden – damit werden die aktuellen Einstellungen mit denen der Richtlinie überschrieben. Ändert man die Richtlinie muss dieser Prozess wiederholt werden. Nachdem die Einstellungen angepasst wurden, kann die geöffnete Datei mittels Ctrl + I neu formatiert werden.

Methode nach Notwendigkeit unter .NET invoken

Manchmal ruft man eine Methode unter .NET aus einem anderen Thread heraus auf. Je nachdem wie die Methode aufgerufen wird, kann es notwendig sein die Methode über Invoke aufzurufen. Mit folgendem Pattern geschieht dies nach Notwendigkeit automatisch:

private void MakeSomeFoo()
{
	MethodInvoker method=delegate
	{
		//Do some foo
		DoSomeFoo();
	};

	if(InvokeRequired) BeginInvoke(method);
	else method.Invoke();
}

Im MethodInvoker-Delegate ist der eigentliche Quellcode der Funktion zu finden. Dieser wird je nach Notwendigkeit im korrekten Thread aufgerufen.