Archiv für den Monat: September 2012

PIBOW: ein schickes Gehäuse für den Raspberry Pi

Heute ist es endlich geliefert worden: mein Pibow, ein schickes Gehäuse für das Raspberry Pi:

20120912-182904.jpg

20120912-182926.jpg

20120912-182952.jpg

Es kleines bisschen Luxus versüßt das Arbeiten 🙂

Bestellen kam man das Gehäuse für ca. 15£ unter folgender Adresse: http://pibow.com/

Man sollte jedoch einige Wartezeit einplanen. Bei mir hat es ca. 6 Wochen gedauert, bis es geliefert wurde.

Raspberry Pi: Erste Versuche

Vor einigen Tagen war es endlich soweit: meinRaspberry Pi ist endlich bei mir angekommen. Wer es nicht kennt: es ist der berühmt 25£ Rechner mit 700 MHz ARM Prozessor, 256 MB RAM, HDMI- und USB-Anschlüssen, sowie einem GPIO-Port.

Hier ist ein Bild des guten Stücks im Betrieb:

20120909-223831.jpg

Die 16GB Speicherkarte habe ich mit Raspbian bespielt:

20120909-224018.jpg

20120909-224005.jpg

    Als mitgelieferte Programmierumgebung muss Python 3.2.3 als Shell herhalten. Eine brauchbare IDE habe ich bisher noch nicht gefunden.
    Da ich als .NET Entwickler wenig Erfahrungen mit Python habe ergeben sich zwei Alternativen:

    • Python lernen
    • Mono auf Raspbian installieren

    Mit beidem werde ich mein Glück versuchen.

    Meine Peripherie ist recht günstig:

    • Amazon Basic HDMI Kabel
    • CAT 5e Patch Kabel
    • SanDisk SDHC 16GB SD Card
    • ein altes USB Ladegerät vom Nokia N97 zur Stromversorgung via USB
    • eine einfache Logitech USB Tastatur
    • eine alte Microsoft 3-Tasten-Maus

    Summe aller Ausgaben inkl. Raspberry Pi: ~70€

    Auf einem 42″ Display zu arbeiten ist für mich eine ganz neue Erfahrung 🙂

    Momentan gibts noch ein paar kleinere Probleme wie beispielsweise Netzwerkprobleme. Wenn ich diese gefixt habe, geht’s los.

    Meine Erfahrungen werde ich hier Schritt für Schritt posten.

    Vorlesung .NET: Ergebnisse der Umfrage der Themen im nächsten Semester

    Am Ende des letzten Semesters habe ich nach der Bekanntgabe der Noten wieder eine Umfrage zu den Themen der Vorlesung im nächsten Semester gemacht. Mir ist es wichtig, dass ich nicht irgendetwas unterrichte, von dem ich meine, es wäre interessant, sondern dass ich die Themen anspreche und vermittle, die wirklich von Interesse sind.

    Das Ergebnis der Umfrage sieht so aus:

    20120909-213346.jpg

    Platz 1 teilen sich sowohl das Testen von .NET Anwendungen als auch die Verteilung von .NET-Anwendungen, sowie Parallele Datenverarbeitung mit der TPL/Multithreading. In der Firma bin ich in einer Taskforce zu dem Thema Parallelisierung unterwegs und kann bestimmt den einen oder anderen Tipp aus der Praxis vermitteln.

    Die folgenden Plätze gehen an GUI Programmierung mit WPF. Hier werde ich neben den Grundlagen in Controls, 2D-, 3D-Programmierung und Animation auch auf MVVM (Model-View-ViewModel eingehen).

    Leider hat das Semester nur 10 Vorlesungseinheiten á 3×45 Minuten, sodass andere Themen wie ASP.NET MVC leider auf der Strecke bleiben. Ich wäre aufgrund der aktuellen Entwicklungen wie Windows 8 von einem anderen Ergebnis ausgegangen.

    Ich freue mich schon auf das neue Semester, das am 1.10.2012 wieder an der Dualen Hochschule Baden-Württemberg beginnt 🙂

    System.IO.FileLoadException: Verwenden von .NET 2.0 Assemblies innerhalb eines .NET 4.0 Prozesses

    Verwendet eine .NET 4.0 Assembly .NET 2.0 Komponenten, kommt es zu einer System.IO.FileLoadException mit der detaillierten Meldung „Die Assembly im gemischten Modus wurde während Version v2.0.50727 der Laufzeit erstellt und kann nicht während der 4.0-Laufzeit ohne zusätzliche Konfigurationsinformationen geladen werden.“:

    Bei mir lag es einfach daran, dass ich eine UI-Bibliothek verwendete, die für die CLR 2.0 entwickelt wurde, während mein Hauptprojekt in .NET 4.0 entwickelt wurde.

    Es gibt mehrere Möglichkeiten, das Problem zu lösen:

    –          Über eine Konfigurationsdatei

    –          Über das Konfigurierung der Aktivierung via Code

    Lösungsmöglichkeit 1: via Konfigurationsdatei

    <startup useLegacyV2RuntimeActivationPolicy=“true“>
    <supportedRuntime version=“v4.0″/>
    </startup>

    Die app.config muss natürlich neben der ausführbaren Datei stehen.

    Beispiel:

    Ausführbare Datei: example.exe
    Konfigurationsdatei: example.exe.config

    Mark Miller hat in einem Blog-Beitrag (als PDF: marklio – What is useLegacyV2RuntimeActivationPolicy for_) beschrieben, wozu die useLegacyV2RuntimeActivationPolicy nun wirklich gut ist und was sie tut.

    Es gibt jedoch Anwendungsfälle, für die man nicht einfach eine Konfigurationsdatei neben die ausführbare Datei legen kann. Ein Beispiel dafür könnte sein, dass eine C-API oder eine COM-API zur Verfügung gestellt wird. Dann kann nicht einfach der ausführbaren Datei, die die C-API verwendet, eine Konfigurationsdatei beigelegt werden.

    Lösungsmöglichkeit 2: via Code

    Im Blog von Reed Copsey bin ich auf einen interessanten Artikel gestoßen, der genau mein Problem löst: http://reedcopsey.com/2011/09/15/setting-uselegacyv2runtimeactivationpolicy-at-runtime/

    Nachfolgend der Code, der für meine Belange (C-API) funktionierte. Jedoch ist die Lösung in Reed Copseys Blog explizit als inoffiziell gekennzeichnet.

    public static bool LegacyV2RuntimeEnabledSuccessfully { get; private set; }

    staticRuntimePolicyHelper()

    {

    ICLRRuntimeInfoclrRuntimeInfo =   (ICLRRuntimeInfo)RuntimeEnvironment.GetRuntimeInterfaceAsObject(Guid.Empty,  typeof(ICLRRuntimeInfo).GUID);

    try

    {

    clrRuntimeInfo.BindAsLegacyV2Runtime();

    LegacyV2RuntimeEnabledSuccessfully = true;

    }

    catch (COMException)

    {

    // This occurs with an HRESULT meaning

    // „A different runtime was already bound to the legacy CLR version 2 activation policy.“

    LegacyV2RuntimeEnabledSuccessfully = false;

    }

    }

    [ComImport]

    [InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]

    [Guid(„BD39D1D2-BA2F-486A-89B0-B4B0CB466891“)]

    private interface ICLRRuntimeInfo

    {

    void xGetVersionString();

    void xGetRuntimeDirectory();

    void xIsLoaded();

    void xIsLoadable();

    void xLoadErrorString();

    void xLoadLibrary();

    void xGetProcAddress();

    void xGetInterface();

    void xSetDefaultStartupFlags();

    void xGetDefaultStartupFlags();

    [MethodImpl(MethodImplOptions.InternalCall, MethodCodeType = MethodCodeType.Runtime)]

    void BindAsLegacyV2Runtime();

    }

    Interessanterweise wird ein statischer Konstruktor verwendet, der unmittelbar nach dem Laden der assembly ausgeführt wird. Dadurch wird der Code implizit von der Runtime ausgeführt und nicht explizit vom Programm selbst. Das sollte ausreichend gut dokumentiert werden, da potentiell nicht jeder im Team den Code sofort versteht und potentiell den Code als „unnütz“ löschen könnte 😉

    Die Eigenschaft „LegacyV2RuntimeEnabledSuccessfully“ gibt an, ob das Umschalten der Runtime-Aktivierung funktioniert hatte. In meinem Fall habe ich eine Ausgabe für die API erstellt, die dem Benutzer angibt, wie er das Problem mithilfe der Konfigurationsdatei lösen kann.