One of the more significant challenges that we have faced during our last project presented itself to us about halfway through the project timeline. Our .Net Micro Framework application regularly sends messages to remote endpoints out on the internet over HTTPS/TCP. In isolation a single HTTPS request using the .Net Micro Framework was a pain free operation (even if there is no HTTPS stack out of the box). However, the problem was that after an indeterminate period of time our application would stop sending HTTP requests and would die a horrible death.

To confound matters further no exception were being raised and so we were not even able to catch the exception to a) gather more information or b) gracefully handle the error. Instead the board would just lock up and stop working, as the .Net Micro Framework runtime had crashed.

Given that we were not receiving an exception of any kind initial testing focused on the hardware that we were running on. We tested our software on both the GHI Master Development System and the Tahoe II board from Device Solutions Ltd yet both products exhibited the same problems.

Focus shifted back to software, but given that no exceptions were throw and connecting to the device using the MF Deploy tool yielded no additional insight we could not ascertain the cause of the problem. Having scoured the code-base for any clues we decided to approach Microsoft with our rather odd problem.

After discussing the many intricacies of our application with the .Net Micro Framework team they provided us with an early build of the MF Deploy tool that was to be released with version 4 of the Framework. As soon as we started using this new version of MF deploy we started making progress.

The first thing that happened is we started to get an exception and stack trace information in the MF Deploy trace information. Now we had something to work from!

#### Exception System.Net.Sockets.SocketException - E_FAIL (1) ####
#### Microsoft.SPOT.Net.SocketNative::socket [IP: 0000] ####
#### System.Net.Sockets.Socket::.ctor [IP: 001f] ####
#### SocketException ErrorCode = 10024

A brief search using Reflector quickly led us to a brief description of the problem:

OK, so apparently we have opened too many sockets. Unfortunately; as is so often the case; this only succeeded in posing more questions than it answered.

Our HTTPS/TCP code opened and closed a socket on every request. Our Socket object was also wrapped in a using statement which meant that it would be disposed of after every call.

IPAddress address = GetHostAddress(uri);

IPEndPoint endpoint = new IPEndPoint(address, 80);

using (Socket socket = new Socket(

    AddressFamily.InterNetwork,

       SocketType.Stream, ProtocolType.Tcp))

{

    //open the socket

    socket.Connect(endpoint);

    //HTTP writing code removed 

    //to keep sample terse.

    //close the socket

    socket.Close();

//dispose the socket

}

So then why do we have too many sockets open? Another look at Reflector only served to strengthen our resolve that we had done everything correctly. The Dispose method did appear to clean up any of the native resources used by the Socket object:

Confused once more we approached Microsoft for an answer to our problems.

It was then that they informed us that by default when you close a Socket in the .Net Micro Framework it does not actually release the Socket for a further 2 minutes! This value is an option that you can set yourself with the following line of code:

socket.SetSocketOption(SocketOptionLevel.Tcp

                               , SocketOptionName.Linger

                               , new byte[] { 0, 0, 0, 0 });

So what is SocketOptionName.Linger? Assuming that it is the same as its big brother equivalent in the .Net Framework it is an option that is used to tell the socket to wait before closing so that any unsent data can be sent.

It should only be necessary to set the Linger time to 0 if you are expecting to open another Socket to the same address and port. If you are to set the Linger time to 0 then it is also recommended that you also set the NoDelay option to true so that any messages are sent immediately.

socket.SetSocketOption(SocketOptionLevel.Tcp

                      , SocketOptionName.NoDelay

                      , true);

Complete example:

IPAddress address = GetHostAddress(uri);

IPEndPoint endpoint = new IPEndPoint(address, 80);

using (Socket socket = new Socket(

        AddressFamily.InterNetwork

       ,SocketType.Stream

       ,ProtocolType.Tcp))

{

    socket.SetSocketOption(SocketOptionLevel.Tcp

        , SocketOptionName.Linger

        , new byte[] { 0, 0, 0, 0 });

    socket.SetSocketOption(SocketOptionLevel.Tcp

        , SocketOptionName.NoDelay, true);

    //open the socket

    socket.Connect(endpoint);

    //HTTP writing code removed 

    //to keep sample terse.

    //close the socket

    socket.Close();

//dispose the socket

}

While we expecienced this problem using version 3 of the .Net Micro Framework, I am not aware whether the default behaviour has been changed in version 4.

This was the first (and simplest) of several intricacies in the .Net Micro Framework that we encountered during the course of this project. More in another blog post soon.

Author: Gavin Osborn
@gavinosborn

Tweet

This article was written from my experiences of working with version 3 of the .Net Micro Framework. Version 4 is now out and promises much – to the best of my knowledge this article is still relevant, but is as yet untested.

The Problem:

So you’ve been working on the .Net Micro Framework for a while. Recently you’ve added a couple of new classes to your project, implemented some new functionality and now it doesn’t compile. Your code has no syntax errors yet when you attempt to compile you get a strange non-descript build error:

The error gives no line of code to look at and the file it references isn’t something you recognise in your project –therefore it doesn’t appear to be a problem with your code, so what’s wrong?

This is one of several particularly unhelpful compile errors you can encounter from time to time when developing for the .Net Micro Framework. To find out more you need to do a little digging...

If you switch to the Output window and review the Build Output you will quickly notice an error that looks something like this:

The first thing you should notice here is that the window appears to successfully compile the project with ‘0 errors & 0 warnings’. Why then does it ultimately fail?

Understanding .Net Micro Framework compilation:

Like regular .Net projects the .Net Micro Framework compilation process is a two stage process.

First the standard C# compiler (csc.exe) is called to compile the project into MSIL, just like any regular .Net assembly. What happens next is where the Micro Framework differs from it’s older brother; Micro Framework applications are not JIT compiled at runtime instead they are optimized at compile time by a tool called the Meta Data Processor. This optimised code is then interpreted at runtime.

The Meta Data Processor performs two functions.

1. Optimise the MSIL for the purpose of size.
Our desktop machines may think nothing of an executable that is 10 MB in size but Micro Framework enabled devices are not likely to have much more than 1MB of space to store and run your application.

2. Optimise the code to use less runtime resources (RAM, etc).
This applies various techniques such the use of a shared string table that stores class member information, text values and other common meta data used by the application.

Part of the optimisations above includes applying some hard internal limits to your applications. This is usually the cause of the above error. To see the more details of the compile error you need to run the MetaDataProcessor in the command prompt using the same arguments that caused it to fail.

You can copy the full command string (this is usually quite large) from the Build Output window (above) and paste it into your command prompt window and run it. The command prompt output should show you the same error but with greater detail:

In this case the maximum size of the shared string table had been exceeded.

The Solution:

The solution itself is fairly simple. These limits are on a per project/assembly basis. So to get around this problem all you need do is split your code into multiple projects. This is usually not too difficult and now that you are aware of these limitations you can start to plan ahead as you build your software project.

Other known Meta Data Processor Errors:

There are several other errors generated by the Meta Data Processor while optimising your code. These are not yet in any form of online documentation (at least none that I could find) that I have read. As a rule every one of these can be resolved by splitting up the project into multiple smaller components.

CLR_E_OUT_OF_RANGE: maximum size of stream 'ByteCode’ – The Micro Framework executable (.pe) files are limited to 65kb of optimised IL code each.

CLR_E_OUT_OF_RANGE: maximum size of stream 'MethodDef' – The number of methods defined in your assembly has exceeded the internal limit.

Of course, now that the latest version of the Micro Framework (including the Meta Data Processor) has been made open source the task of  hunting down the cause of these errors should be much simpler.

@gavinosborn

Tweet

The .NET Micro Framework enables devices to be developed using the same managed C# language and Visual Studio tools we use for all our other projects. More details about the .NET Micro Framework can be found on the Microsoft site.

At Dot Net Solutions, we have a strong belief in Agile development and XP programming. So when we started to develop for the .NET Micro Framework, we immediately looked for its support for unit testing. However, we discovered that there was no support available. Not to be deterred from our ethos, we undertook to create our own.

The .NET Micro Framework supports reflection, thereby, giving the ability to execute “Test” methods. However, the .NET Micro Framework does not provide support for custom attributes, therefore, the following is not possible:

[TestMethod] //no custom attributes

public void TestStartsWith()

{

   ...

}

Instead, we used a convention based approach, requiring the word “Test” to be prefixing to all test methods names. We can then use reflection to call all public instance methods starting with “Test”.

Type[] types = assembly.GetTypes();

foreach (var type in types)

{                

    MethodInfo[] methods = 

        type.GetMethods(BindingFlags.Public

                        |BindingFlags.Instance);

    foreach (var method in methods)

    {

        if (method.Name.Length >= 4 && 

            method.Name.Substring(0, 4) == "Test")

        {

            ...omitted 

            try

            {

                method.Invoke(null, null);

            }

            catch (Exception ex)

            {

                result.Status = ResultType.Fail;

                result.Exception = ex;

            }

            OnDisplayTestResult(new TestResultEventArgs 

                    { TestResult = result });

        }

    }

}

Using this naming convention for test methods and reflection to execute those methods provides part of the solution. The next challenge was to provide a host that would enable this approach to be used. Here the .NET Micro Framework does provide a solution. Our approach was to create a test harness project that would iterate all test methods in all test assemblies and execute them. The results are displayed in a custom emulator, which is set as the Deployment device for the test harness project.

This emulator provides a simple user interface, allowing the number of successful test to be seen and information on any failing tests.

There is one critical part missing and that is the ability to “Assert” the expected outcome of a test and to manage the case where this assertion fails. A simple Assert class can be created for this with a number of static methods, such as IsTrue. This enables this common unit testing syntax, e.g. Assert.IsTrue, to be used in tests:

public void TestStartsWith()

{

    string _testString = "freakyKey";

    Assert.IsTrue(!_testString.StartsWith("gav")

        , "The string freakyKey does not start with 'gav'");

    Assert.IsTrue(_testString.StartsWith("freak")

        , "The string freakyKey does start with 'freak'");

}

The implementation of Assert.IsTrue is shown below:

/// <summary>

/// Assert whether the specified condition is true.

/// </summary>

/// <param name="condition">The condition to test.</param>

/// <param name="message">The message.</param>

public static void IsTrue(bool condition, string message)

{

    if (!condition)

    {

        throw new AssertException(message);

    }

}

We could have stopped there but how do we know that our framework does what we expect? We unit test it of course! We actually used our unit test framework... to test our unit test framework. Cool!

The unit test for the Assert.IsTrue method looks like this:

public void TestIsTrueAssertTrue()

{

    try

    {

        Assert.IsTrue(true

            , "This should not throw an exception");

    }

    catch (AssertException)

    {

        throw new AssertException(

        "Assert.IsTrue should not throw an exception for true");

    }

}

While the .NET Micro Framework does not provide support for unit testing out of the box, this should not deter you. The creation of a unit testing framework (and even testing that framework) can be achieved with a little effort.

Author: Marcus Tillett
@drmarcustillett

Tweet

Here at Dot Net Solutions, we have been working on a project using the .NET Micro Framework for the past year. The .NET Micro Framework enables devices to be developed using the same managed C# language and Visual Studio tools we use for all our other projects.

More details about the .NET Micro Framework can be found on the Microsoft site. Much of the development and initial testing was done against the Tahoe II board from Device Solutions. However, the target hardware was somewhat different from this.

During the course of the project we discovered a number of interesting features of the .NET Micro Framework. Some of which relate specifically to version 3.0 and others that continue to be true for version 4.0. We have a number of blog posts planned to cover these soon.

One of the most challenging aspects of the project was the need to develop the software without access to the target hardware. This factor has been picked up by Microsoft in this recent case study, which is currently on the Micro Framework site Case Study from Dot Net Solutions.

@drmarcustillett

Tweet

About once a week Johan sends out a company tweet about cool stuff that people were working with on Friday afternoon. I was on the way back from holiday but I did see something interesting.

Several months back I switched from a rival navigation system to a TomTom navigation system, and on Friday afternoon the TomTom asked me to make a U-Turn and showed exactly where to make the turn.

With the previous system that would mean I’d missed a turning, but the TomTom is looking ahead for me. As I crested the hill I could see the traffic jam on the opposite side of the valley. The turning point recommended was barely 50moff the tail end of the queue and a couple of turns later I was chasing down an empty B road almost parallel with the original route and picking apart what just happened.

Speculatively I think the following series of events occurred.

1) Several vehicles were stopped in that jam with TomTom devices on board

2)  These alerted home what was happening and TomTom updated a central database of traffic speeds

3) My TomTom called home to check conditions on the route

4) It noted that the route conditions had changed and started looking for alternate routes

5) It recommended a new route and validated conditions with the central server

6) I saved 20-30 minutes in a traffic jam (which would have increased my frustration and my fuel consumption)

7) I got home happy

Microsoft and Gold Partners such as Dot Net Solutions frequently talk about how a Software + Services approach enhances systems design and introduces new business capabilities. It’s right here in my little story. By sharing data about where I am and how fast I’m moving I enable TomTom to calculate more accurate, live traffic data. The services infrastructure enables them to aggregate this data and sell it back to me in a useful format. The Software on my device uses that data when available to optimize my route

I traded personal data and cash for anonymised data and a program that gave me a better experience. It’s clear that TomTom get a lot out of the arrangement as well – they’re not entirely a ‘device’ company they’re a data services company that gives them an edge when people are just evaluating the devices, and gives them a long term relationship with their customers with repeat income.

What data will your customers give you? Can we help you process that data live and make it available to them?