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.

I don't use LINQ terribly often because it seems that most of the work I do is pre-CF 3.5.  It only creeps into my code in things like unit tests or test projects. 

This weekend I spent a little time updating my AudioTagR project and adding some tools and utilities to it.  One of the challenges I faced was let's assume I have two root directories that contain music files (they really can be any file, but this is a real-world example, so we'll use the exact scenario I had).  In each of these roots are folders for Artists.  In each of those are one or more folders that represent albums by that artist.

Now let's assume one of those root folders (Root A) is my "root" music collection and it contains a few thousand artists.  The other root folder (Root B) is a collection of music off my old hard drives, CDs, etc.  I know that there are duplicates between these folders - artists that exist in both as well as albums that exist in both.  I want to go through Root B and move only those albums to Root A if they don't already exist.  That means that I want to move all albums that aren't already in Root A, creating the containing Artist folder if it's there.  If the folder is there, I want to skip it and I'll manually check the list of songs later.

The traditional way to do this would be to write a recursive method that would look something like this pseudocode:

void Parse(sourcefolder, destfolder)
{
   foreach(directory in sourcefolder.directories)
   {
       if(! exists(destfolder[folder]))
       {
          Copy(sourcefolder, destfolder);
       }
       else
       {
           Parse(directory, destfolder + directory);
       }
   }
}

Well since this code really is nothing but a series of operations on a collection, LINQ immediately comes to mind as a good fit.

The first challenge I ran into is that my algorithm requires a list of directories contained in a parent directory.  Unfortunately Directory.GetDirectories returns a list with the fully qualified path and I just needed the name of the folder itself.  So I wrote a couple of extension methods that get purely a list of the directory names, not the paths.  I also added one for checking to see if a directory was empty (to be used later for cleanliness):

public static class IO
{
  publicstaticbool IsEmptyDirectory(thisstring path)
  {
    return (Directory.GetDirectories(path).Count() + Directory.GetFiles(path).Count()) == 0;
  }

  publicstaticstring FolderNameWithoutPath(thisstring path)
  {
    return Path.GetFileName(path);
  }

  publicstaticstring[] GetFolderNamesWithoutPath(thisstring path)
  {
    return (from folder in Directory.GetDirectories(path)
        select folder.FolderNameWithoutPath()).ToArray();
  }
}

Once I had those, the resulting merge method was a simple iteration across a couple LINQ queries.

privatevoid MergeFolders(string sourceFolder, string destinationFolder)
{
  // copy those in A but not in B
  foreach(string folder in
      sourceFolder.GetFolderNamesWithoutPath().Except(
      destinationFolder.GetFolderNamesWithoutPath(), StringComparer.InvariantCultureIgnoreCase))
  {
    Directory.Move(Path.Combine(sourceFolder, folder), Path.Combine(destinationFolder, folder));
  }

  // now go through those in both and repeat
  foreach (string folder in
      sourceFolder.GetFolderNamesWithoutPath().Intersect(
      destinationFolder.GetFolderNamesWithoutPath(), StringComparer.InvariantCultureIgnoreCase))
  {
    string src = Path.Combine(sourceFolder, folder);
    MergeFolders(src, Path.Combine(destinationFolder, folder));

    if (src.IsEmptyDirectory()) Directory.Delete(src);
  }
}

Finally!  Someone has created a code profiler for the .NET Compact Framework.  And what's even more exciting is that it's free.  I've not used it, so I can't vouch for how well it works, or how easy it is to use, but the fact it exists is quite promising.

Ever since learning how to use function pointers in C, I've always been a fan of using them to help make code a bit more usable, especially when you've got a state machine.  Today, as I'm working on a Wizard UI for a desktop application I came across a typical scenario for using a function pointer.  Depending on the stage of the Wizard you're in, a button will have to do separate things.

That got me to thinking that most managed developers simply don't understand the power and utility of delegates, but instead simply consider them a necessity when using Control.Invoke or creating custom events. Sure, in my case I could have a switch statement in the click handler and do logic there, or I could unhook the click handler from one method and hook it to another, but those all seem ugly and a pain in the ass to me.  A simple function pointer change is all you need.  So I decided I'd throw together a really simple example of how you would use a delegate to change the behavior of a Button click.

Let's assume that we have a button that we want to click, and when it's clicked it will do one of 4 things, depending on the state of our application.  We'll just use a messagebox here to give you the idea - what it does is up to you- it's a function after all.

public void FunctionA()
{
  MessageBox.Show("FunctionA");
}

publicvoid FunctionB()
{
  MessageBox.Show("FunctionB");
}

publicvoid FunctionC()
{
  MessageBox.Show("FunctionC");
}

publicvoid FunctionD()
{
  MessageBox.Show("FunctionD");
}

To simulate the different "states" I simply added a ListBox (called functionList) to the Form and manually added the function names to it in the Form's constructor.  Sure, I could have used Reflection to be clever and populate the list, but I'm tryiong to keep it simple and show delegates.

functionList.Items.Add("FunctionA");
functionList.Items.Add("FunctionB");
functionList.Items.Add("FunctionC");
functionList.Items.Add("FunctionD");

Alright, so now we know that depending on which item is selected, we want to call one of our four functions.  Since they all have the same interface (and they have to to use a delegate) we simply define a delegate that matches them.  This delegate can be privately scoped inside your class.

delegate void FunctionDelegate();

And then we create an instance variable to hold the current function pointer we want to use:

private FunctionDelegate m_functionPointer = null ;

We add an event handler for the SelectedIndexChanged event of the ListBox (in the Form constructor)

functionList.SelectedIndexChanged += new EventHandler(functionList_SelectedIndexChanged);

And implement the event handler.  It simply looks at the newly selected index in the list and changes the value stored in m_functionPointer appropriately.

void functionList_SelectedIndexChanged(object sender, EventArgs e)
{
  // determine which function pointer to store based on selection
  switch (functionList.SelectedIndex)
  {
    case 0:
      m_functionPointer = FunctionA;
      break;
    case 1:
      m_functionPointer = FunctionB;
      break;
    case 2:
      m_functionPointer = FunctionC;
      break;
    case 3:
      m_functionPointer = FunctionD;
      break;
    default:
      m_functionPointer =null;
      break;
  }
}

Next we wire up an event handler for our button (again the the Form constructor):

callButton.Click += new EventHandler(callButton_Click);

And finally the magic and simplicity of the state-dependent call

void callButton_Click(object sender, EventArgs e)
{
  // call our function (as long as it's not null)
  if (m_functionPointer !=null)
  {
    m_functionPointer();
  }
}

That's all there is to it.  Run the application, select a function and click the button.

Get the full source here.

In a recent project we decided to migrate the application's data engine from SQL CE 3.1 to SQL CE 3.5.  The challenge with this is that the file formats themselves are not compatible and trying to connect to a 3.1 database usign the 3.5 objects will cause an Exception.  3.5 provides a method to upgrade 3.1 database files, but to use it you really need to know that the file is in 3.1 format to begin with.

Of course you could always put in logic to connect and catch the exception and then upgrade, but let's face it - using exceptions for flow control is a bad practice and any ime it can be avoided it should be. 

Surprisingly, the SQL CE team didn't give us any mechanism otherwise to determine a database file's version, so I put together the following (which should work on the desktop as well as the device):

internal enum SSCEVersion
{
    Unknown,
    v3_1,
    v3_5
}

internalstatic SSCEVersion GetDatabaseVersion(string path)
{
    uint signature = 0;

    using (FileStream stream =new FileStream(path, FileMode.Open))
    {
        using (BinaryReader reader =new BinaryReader(stream))
        {
            stream.Seek(16, SeekOrigin.Begin);

            signature = reader.ReadUInt32();
        }
    }

    switch (signature)
    {
        case 0x00357b9d: // 3.5
            return SSCEVersion.v3_5;
        case 0x002dd714: // 3.1
            return SSCEVersion.v3_1;
        default:
            return SSCEVersion.Unknown;
    }
}