Problem A
I have an application that transfers data to another app via (serial/CAN/Ethernet/can-and-string/cheese stream ion a macaroni pipe/whatever).  I have set up a send and acknowlege paradigm so I know when the receiver has all of the data, but I need to know that what the other end received is correct.  What does the SDF do for me?

Problem B
I have an application that receives a file from a native application.  The application send me a 'checksum' along with the data and the native guys tell me that I must use that checksum value to make sure that the data I received has not been corrupted.  I vaguely understand what a checksum is, but I have no clue how to calculate one from the file.  What does the SDF do for me?

Solution
[Tested on a custom PXA270-based Windows CE 5.0 device *and* the desktop (full framework 2.0)]

Nicely enough, the SDF solves both of these with the use of the OpenNETCF.CRC class. The CRC (short for Cyclic Redundancy Check) class supports generating a CRC for a byte array or a FileStream.

Here's what usage for a file looks like.  This creates a 32-bit checksum (we support 8-64 bit) using a standard ploynomial (we support any custom polynomial too):

FileStream fs = File.OpenRead(sourceFileName);
uint checksum = (uint)OpenNETCF.CRC.GenerateChecksum(fs, 32, (ulong)OpenNETCF.CRCPolynomial.CRC_CCITT32);
fs.Close();

Sometimes we tend to forget just how useful the Smart Device Framework really is.  There are tons of little gems in it that we put in there, some times years ago, and then we forget about it.  I have a general idea of what all is there, but by no means can I tell you everything, so when I need a feature in an app, I always go look to see if we've already done it.

Unfortunately we tend to lack concrete examples of how a lot of it can help you in your everyday work.  In an effort to rectify that, over the coming months all of us here at OpenNETCF will be blogging short snippets of cool, useful stuff you can do.  We also are taking requests.

So here's one.  

Problem
I have a device and we want to know when a storage device (USB, CF, PCMCIA, SD, etc.) is either inserted or removed.  What does the SDF do for me?

Solution

[Developed and tested on an OLDI 56SAM-400 800MHz x86 device running CE 5.0]

private DeviceStatusMonitor m_diskMonitor;

public MyClass()
{
    ...
    m_diskMonitor = new DeviceStatusMonitor(DeviceStatusMonitor.FATFS_MOUNT_GUID, false);
    m_diskMonitor.DeviceNotification += FATMounted;
    m_diskMonitor.StartStatusMonitoring();
    ...
}

~MyClass()
{
    m_diskMonitor.StopStatusMonitoring();
}

void FATMounted(object sender, DeviceNotificationArgs e)
{
    Trace2.WriteLine(string.Format("FAT device '{0}' {1}mounted", e.DeviceName, e.DeviceAttached ? "" : "un"));
}

The DeviceStatusMonitor ctor's first parameter can be a few things - I've chosen FAT file system (we can detect a CD too!).

The thing I don't understand is how the hell this class ended up in the OpenNETCF.Net namespace.  Expect that to change in 2.2.  I'll probably deprecate the existing classes with a warning and move them somewhere that it makes sense.  I may also streamline the usage as well.

Today someone asked how they might enumerate all files and folders on a device.  The concept is pretty simple, and implementing it with a recursive algorithm is straightforward.  To make it a bit more useful I'm adding the items to a TreeView and saving the full path to the display file/folder in the TreeNode's Tag property, so when a node is selected, you don't have to reassemble the path.

Code:

public void GetListOfAllFilesAndFolders(TreeView view)
{
    view.BeginUpdate();
    view.Nodes.Clear();
    TreeNode node = new TreeNode("My Device");

    AddFolderToTreeNode("\\", node);
    view.Nodes.Add(node);
    view.EndUpdate();
}

private void AddFolderToTreeNode(string rootPath, TreeNode rootNode)
{
    // add in all directories
    string[] dirList = Directory.GetDirectories(rootPath);

    foreach (string dir in dirList)
    {
        TreeNode node = new TreeNode(Path.GetFileName(dir));
        node.Tag = dir;
        AddFolderToTreeNode((string)node.Tag, node);
        rootNode.Nodes.Add(node);
    }

    // add all files
    string[] fileList = System.IO.Directory.GetFiles(rootPath);

    foreach (string file in fileList)
    {
        TreeNode node = new TreeNode(Path.GetFileName(file));
        node.Tag = file;
        rootNode.Nodes.Add(node);
    }
}

Usage:

GetListOfAllFilesAndFolders(treeView1);

Yes, It's that simple.

NOTE: I tested this on an OLDI 56SAM-400 800MHz x86 CE device running CE 5.0 so your mileage may vary.

If you've done much development on non-Windows Mobile CE devices I'm sure your painfully aware of the pain in the ass process of getting Visual Studio 2005 to actually attach to the device.  Lately I've been doing nothing but non-WM development and deviced to automate and solidify the process, plus document it while I was at it.

We've got a (native) tool called CEDbgSetup that you run on your device (x86 or ARMv4I supported) and then you set up Studio once and only once, then you can debug every time using wired Ethernet, 802.11, USB RNDIS (and likely any other transport that uses TCP/IP) and without ActiveSync.

The tool supports auto-launching from \Windows\Startup or by setting up an LaunchXX entry in HKLM\Init in the device registry, or just manual click.  It should work headless too, though I've not specifically tested it.

It works with native or managed apps.

The tool, along with full source can be downloaded here (607k zip).

A white paper on how to set up Visual Studio 2005 can be viewed here (144k PDF).

Feedback is appreciated, but keep in mind that its free and completely unsupported (read: don't ask me for support).

Another feature that missed the 2.1 cutoff - we've added a couple things to our existing EventWaitHandle:

A Set() overload:
public bool Set(int data)

A GetData method:
public int GetData()

For simple, fast, and really easy to implement IPC you can just do this:

Process A
EventWaitHandle wh = new EventWaitHandle(false, EventResetMode.AutoReset, "MY_EVENT_NAME");

int myData = 10;
wh.Set(myData);

Process B
EventWaitHandle wh = new EventWaitHandle(false, EventResetMode.AutoReset, "MY_EVENT_NAME");

I know, SDF 2.1 has only been out for a day, but we're always working on the code base.  I just wrapped up a namespace that didn't make the 2.1 cutoff: OpenNETCF.WindowsCE.Services.  It allows you to enumerate, start, stop, refresh, load, unload, set the debug mask and register for autostart any service on the device.

Moving forward we're trying to componentize the SDF, so this one is stand-alone with no additional dependencies (not even the core OpenNETCF.dll library)

Here's a screen shot of my test/sample harness: