Heute ist es endlich geliefert worden: mein Pibow, ein schickes Gehäuse für das Raspberry Pi:
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.
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:
Die 16GB Speicherkarte habe ich mit Raspbian bespielt:
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:
Mit beidem werde ich mein Glück versuchen.
Meine Peripherie ist recht günstig:
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.
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:
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 🙂
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.