Thursday, December 29, 2005

NUnit and Compact Framework Applications

I recently learned about Test Driven Development and got really excited. Until, that is, I discovered that my version of Visual Studio doesn't have the great new tools for team development. For that you need one of the Team editions, but at more than $5,000, I wasn't quire ready to take the plunge.

So I decided to try NUnit, which is an open source application for testing .NET applications.And it works, within some well-defined cases.

There are limits to what you can and cannot test using NUnit to test your Windows Mobile applications. Since NUnit is running on the desktop, your unit tests also run on the desktop rather than a Windows Mobile platform (device or emulator). If your testing code that isn't dependent on the Windows Mobile platform, you should be able to write and run unit tests on the desktop because your CF applications classes will load and run on the desktop as long as they don't require PocketPC/Smartphone-specific code (such as PInvoke calls to coredll).

Of course, it would be far better to test your code on the target platform, or at least for some test cases. Right now there is only one test harness I'm aware of that runs on Windows Mobile itself: CFNUnitBridge. I haven't tried this yet, but I'm just getting started with test-driven development.

Friday, December 02, 2005

A resource nightmare on .NET street

Well, I had a fun afternoon. I have a program for the Pocket PC that I just put into alpha. I've written this program using the .NET Compact Framework 1.1. I of course upgraded my development environment to Visual Studio 2005 when it was released about a month ago, however I continued to use version 1.1 of the .NET CF. No problem.

That is, until today when I decided to change one string in my resource file. Once I did that, I kept getting runtime errors when I attempted to read a value from the embedded string resource. First I got an ArgumentError exception, then I got a TypeLoadException. How could that be? My resource code has been working for a long time and I didn't change a single line of code--I just edited the value of a resource string.

After a number of hours trying different things I finally figured it out. I hadn't edited the resource file in quite some time and, as it turned out, I had upgraded the program I was using to edit my resource files, which were in the ".resource" format. I started using a program called Resourcer back when I was using Visual Studio 2002. Recently I decided to get the latest and greatest version, which was labeled ".NET Framework 2.0.50727." What I didn't know, and which now makes sense, is that the author, Lutz Roeder, delivers three different versions of the same program that bind to different versions of the .NET framework. And each of these versions writes a .resource file tied to the same version of the .NET framework.

So when I modified a string and saved the file, Resourcer overwrote the old .NET 1.1 file with a .NET 2.0 file. When I looked more closely at the strings in this file, I noticed that the type for each string is "System.String, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKey Token=b77a5c561934e089." Notice the version number? When I called the resource manager's GetObject method, it attempted to create a 2.0 instance of the type, but this application is running on a device with 1.1 on it, so the create failed.

But the story doesn't end there. I wasn't able to open this file with a "previous" version of Resourcer because the versions for older .NET frameworks weren't able to load the newer types. Fortunately, I was able to use Resourcer to save the file as a .resX file, which I could then include in my project. In the process, I also discovered that Visual Studio 2005 contains a fabulous built-in resource editor that makes Resourcer obsolete.