private KeyboardHook m_keyHook;
    
    public Form1()
    {
      m_keyHook = new KeyboardHook();
      m_keyHook.KeyDetected += OnKeyDetected;
      m_keyHook.Enabled = true;
    }

    void OnKeyDetected(OpenNETCF.Win32.WM keyMessage, KeyData keyData)
    {
      // Do Stuff
    } 

   Radios radios = Radios.GetRadios();


   Debug.WriteLine("\nBefore\r\n--------");

   foreach (IRadio radio in radios)

   {

     Debug.WriteLine(string.Format("Name: {0}, Type: {1}, State: {2}", radio.DeviceName,
   radio.RadioType.ToString(), radio.RadioState.ToString()));


     // toggle all radio states

     radio.RadioState = (radio.RadioState == RadioState.On) ? RadioState.Off : RadioState.On;

   }


   // give the radios enough time to change state - some (like BT) seem to be slow

   Thread.Sleep(1000);


   radios.Refresh();


   // display again

   Debug.WriteLine("\r\nAfter\r\n--------");

   foreach (IRadio radio in radios)

   {

     Debug.WriteLine(string.Format("Name: {0}, Type: {1}, State: {2}", radio.DeviceName,
   radio.RadioType.ToString(), radio.RadioState.ToString()));

   }

   Debug.WriteLine("\r\n\n");

   Thread.Sleep(100);

We've been working for a couple months now at migrating some of our projects from our older SourceGear Vault source code repository to Microsoft's Team Foundation Server.  I've been perfectly happy with Vault - it's a great, inexpensive code repository - but we wanted to start doing test driven design and adding continuous integration into the mix.  One would think that since that's what TFS is all about that this would be pretty simple, right?  Hardly.

TFS may work out of the box for desktop developers, but when it comes to doing device work you quickly end up in a tar pit of problems, which is only compounded when you're new to TFS to begin with.  In my opinion a root of these problems is that the Visual Studio IDE is not using msbuild.exe and mstest.exe for doing device project builds and tests.  This is evidenced by the fact that you can create a device project with unit tests and they all run just happily from the IDE, but if you open a command windows and use msbuild with your solution it fails miserably.

I consider this a major failure on the part of the Visual Studio for Devices (VSD) team.  You see TFS doesn't launch Studio to build your solution, it uses msbuild.  So to just get the solution to compile you have to learn how TFS works and make modifications.  Oh, and once it's compiling that certainly doesn't mean that unit tests will actually run.  We've hit several snags along the way on that too.

Fortunately for us, I have a good friend and long-time colleague, Tim Bassett, who is big into CI and TDD, has a lot of experience with TFS and is considering hanging out his own shingle. He just has no experience doing device development (well not really any since the days of eVB when we worked together).  So we formed a kind of symbiotic relationship with him helping us getting our server working and running and us helping him develop some products that will benefit any other hapless suckers who think that maybe automating builds and testing for device development might be useful.  If you're in that boat, take a look at what he's got. Ask him questions.  Help him help us improve the experience of using TFS for device work. And if you ever have the ear of anyone on the VSD or CF team, tell them they should be dogfooding this stuff so they can feel our pain and that yes, unit tests for native code *is* necessary.

For some time now we've offered "support and maintenance" as an option when purchasing our flagship Smart Device Framework product.  If I recall correctly, the price is something like $240 for a year.  In the entire time we've offered it I can probably count the number of sales of that option on one hand - it's way less than 1% of the people who bought the extensions.

I had a call from a prospective customer asking about the feature and it clued me in to what most people's thought process is.  He asked "why should I buy maintenance for $240 when I can just buy each new version for $50.  It's less expensive to just re-buy."

Ah, on the surface that may seem true, and like a good deal.  But here's the value in buying maintenance:

Right now we're in the process of moving the SDF to Studio 2008.  In the process we're also moving to using Team Foundation Server as a back end and integrating unit testing and continuious integration.  In this process we're shaking out quite a few bugs (take a look at our online bug database to see what we're up to).  People with maintenance agreements can request the source for these fixes at any time.  They also get source drops for all service packs (no one else does).  Those without maintenance must wait until the next release or service pack to take advantage of these fixes.

There is one exception to this rule.  We feel that if you've gone through the task of finding it and reporting it, we owe you so if you are the first to find and report a bug, we'll provide you the fix immediately upon fixing it. 

We're just about to release a new version of Padarn, out ASP.NET Web Server for Windows CE.  This version brings SSL support as well as Basic and Digest authentication.  Another part of this release was trying to keep the footprint reasonably small.  Here's a screen shot of all of the assemblies needed for the entire engine implementation:

So yes, we have an ASP.NET web server with SSL and authentication support and it's just 305KB - and half of that is for SSL alone.