Heute bin ich über ein Problem gestolpert, das mich etwas schockiert hat. Wir setzen NUnit in Verbindung mit CruiseControl für den Test eines Embedded Systems ein. Die NUnit-Test werden mit .NET 3.5 entwickelt. Um mit dem Device kommunizieren zu können, gibt es ein proprietäres Netzwerkprotokoll, für das wir eine .NET-API entwickelt haben. Diese API wird gegen .NET 2.0 und .NET CF 2.0 kompiliert.

In meiner letzten Erweiterung der API habe ich unter anderem eine Ressource mit einem Mutex verriegelt. Der anschließende Entwicklertest verlief unauffällig, sodass die neue API sozusagen “RTM” wurde und an den Testentwickler ging, der die neuen Tests gegen die API programmieren sollte. Dabei stolperte er relativ schnell über eine MissingMethodException. Interessant war, dass dies durch den Aufruf von Mutex.WaitOne(Int32) hervorgerufen wurde. Darauf konnte ich mir nun gar keine Reim machen, da diese Funktion so vertraut schien. Ist sie aber nicht.

Mutex.WaitOne(Int32) ist eine neue Überladung der Funktion WaitOne(). Bisher gab es diese ohne Parameter, WaitOne(), oder mit zweien, WaitOne(Int32, Boolean) und WaitOne(TimeSpan, Boolean). Die Überladungen WaitOne(Int32) und WaitOne(TimeSpan) sind erst mit dem Service Pack 1 für .NET 3.5 hinzugekommen. Prinzipiell sollten sie damit auch nur in.NET 3.5 verfügbar sein. In .NET 2.0 sind sie nun deshalb enthalten, weil die WaitHandle-Klasse im Namensraum System.Threading untergebracht ist, der in mscorlib enthalten ist. Diese Assembly liegt nur in der Version 2.0 vor. So lange also .NET 3.5 SP1 installiert ist, ist alles ok. Wenn nicht, ist das jedoch nicht so schön, da man während der Entwicklung den Fehler nicht bemerkt.

Hoffentlich ist das der einzige Fallstrick, der durch .NET 3.5 SP1 für .NET 2.0-Entwicklungen gelegt wurde. Oder kennt jemand andere?

Es tickern seit einigen Tagen ein paar Gerüchte durch das Netz, dass Microsoft den Quellcode des .NET Micro Framework an die Community übergeben und sich selbst aus der Entwicklung zurückziehen will. Die entsprechenden Entwickler sollen in das Server and Tools Department übernommen werden, sofern sie nicht das Unternehmen komplett verlassen müssen.

Ich bin mir noch nicht vollkommen sicher, was ich von dieser Entwicklung zu halten habe. Ich habe bereits vor dem Erscheinen der Version 2.0 das Thema in der Firma angesprochen, da wir gerade daran waren, ein größeren Embedded-Projekt aufzulegen. Damals haben sich die Entscheidungsträger gegen das .NETMF entschieden, da es erst sehr kurz auf auf dem Markt ist und es sich somit auch nur um eine Modeerscheinung handeln kann. Wenn nun das Projekt in die OpenSource-Gemeinde übergeht, könnte für einige Firmen nun das Problem des fehlenden Herstellers (in rechtlicher wie technischer) Sicht ein Problem werden. Andererseits wird durch dieses Vorgehen das Framework wahrscheinlich schneller entwickelt und sich auch eher verbreiten. Dabei kann es jedoch passieren, dass sich die schnellere Entwicklung negativ auf das Produkt auswirkt.

Ich schätze, die Zeit wird zeigen, wie es weiter geht. Und solange die Zukunft des .NETMF nicht geklärt oder wenigsten klar abzusehen ist, ist jede Firma gut beraten, das Ganze mit Vorsicht zu genießen.

Semioffizielle Statements des .NETMF-Teams (dort wird auf nachfolgende offizielle Statements verwiesen, die jedoch noch nicht erschienen sind):

.NET MF moves to Developer Division

.NET Micro Framework evolution

Einige Reaktionen aus dem Netz:

Microsoft to turn .Net Micro Framework code, support over to the community

.NET Micro Framework Future (not a dead project!!)

.NET MF moves to Developer Division

Microsoft Will Open Up .NET Micro Framework Source Code

.NET Micro Framework könnte Open Source werden

Last friday, June 6th, the Microsoft .Net Microframework Team announced a new version 3.0 of the .Net Micro framework. Several cool features are supported, for example a file system, toch screen support and the development environment was changed to VS2008. Have a look at the complete list of new features. Now I hope that Device Solutions will update the Tahoe firmware as soon as possible so that I can profit from the new features.

Ich hoffe, dass mein Handyvertrag jetzt schneller ausläuft und mein Provider des Vertrauens das kleine Juwel in sein Portfolio übernimmt. Man sehe uns staune... das iPhone ist ja wohl ein Witz dagegen. Darauf läuft ja noch nicht einmal ein .NET Framework ;)

The project I'm currently working on is an embedded device without any graphical interface capability. The only ways to get some information out is the NIC or a serial port. There is also a CAN-Bus interface, but as far as my company developed the device it is better to not base our debugging capabilities on a potentially buggy part of the system. Out first debug out was implemented as a serial output tracer. As the day comes closer that out hardware prototypes will arrive, the higher the need to port the tracing over to the NIC as far as the final hardware won't have a serial port on it.
So last week the network tracer was check in into source control. Now, how to read these information?
Windows ships with Hyper Terminal. But this isn't very comfortable and you manually have to reestablish a lost connection. In my today's lunch break I wrote a small powershell script that listens to the network socket. At the moment I'm porting it to C# to add some more features.

But here is the first part, a small and simple powershell script to listen to a network socket. But please let me clarify that this is code snippet is NOT the way code. It was a fast hack to get it running. There is no error handling and ressources are not freed gracefully as it has to be terminated with ctrl + c. In clear words: This is a sample on how to receive data from a network socket.

$socket = new-object System.Net.Sockets.TcpClient("172.16.170.123", 9950)
if($socket -eq $null) { return; }
$stream = $socket.GetStream()
$buffer = new-object System.Byte[] $socket.ReceiveBufferSize
$encoding = new-object System.Text.AsciiEncoding

while($true)
{
   if($stream.DataAvailable)
   {
      $read = $stream.Read($buffer, 0, $socket.ReceiveBufferSize)  
      write-host -n ($encoding.GetString($buffer, 0, $read))
   }
}

From a post ont the Windows Embedded blog - Microsoft announced some name changes for their embedded products:

• Windows Embedded CE is now known under Windows Embedded Compact
• Windows XP Embedded is now known under Windows Embedded Standard
• Operating systems wich embedded licences are now known under Windows Embedded Enterprise
• Point of Service applikations and platforms are now known under Windows Embedded POSReady