Unable to set TestContext property for my class (.NET Compact Framework)

Suppose you’re using Visual Studio 2008 and you’ve just found out that Microsoft added unit test support for the Compact Framework on devices and emulators. Neat-o!

So you add one to your project thinking, this’ll be fantastic.

Then it doesn’t work.

You get the following cryptic error:

Unable to set TestContext property for the class {class}. Error:  System.ArgumentException: Object of type 'Microsoft.VisualStudio.TestTools.TestTypes.Unit.UnitTestAdapterContext' cannot be converted to type 'Microsoft.VisualStudio.TestTools.UnitTesting.TestContext'

“So,” you think, “I obviously did something wrong, but it’s not apparent to me what I did. I will check the Google.”

But Google only shows you what to do for the full framework.The answer for the full framework is to delete your reference to Microsoft.VisualStudio.QualityTools.UnitTestFramework, then search for it again in the Add Reference dialog. Microsoft forgot to update all the project templates for VS08, so all of the esoteric projects point to the assemblies for VS 2005. Quality tool, my ass. The full framework instructions don’t make any sense for your awesome Compact Framework assembly. Uh oh, now what are you going to do?

Maybe it’s your project that’s screwed up. So you start a new one to see if it works. It doesn’t, but you get a different error: References root node unavailable. You might as well search the google for that one and then you get this forum post that repeats the solution over and over:

Restart the IDE.

You figure it can’t hurt, so you try it.

And it works.

You can now use unit tests for .NET CF projects, but you’re no longer smiling about it.

The WPF Application Class: Overview and Gotcha

I’ve written often lately about WPF, including BabySmash posts and Missing .NET articles. I’ve decided to do a complete app using WPF. I’ve dabbled here and there with the concepts, but I’ve decided I don’t really know the framework that well. I still have to look up how to do something basic like master-detail data binding. So I set out to do something fairly basic and (barely) doable by one person – kind of what Scott Hanselman is doing with BabySmash, but a little more traditional, so I can take advantage of more of WPF. I shan’t disclose the function of the app for now, because it’s no where near ready. I will, however, document some things I run into, either because they were so useful, but not really advertised, or because I’ve found sharp rocks in the shallows and must warn others. This post is a bit of both.

If you use Visual Studio, this is obscured from you, but every WPF application must contain the equivalent of the following Main

[STAThread]
public static void Main(string[] args)
{
    Application app = new Application();
    Window win = new Window();
    win.Show();
    app.Run();    
}

Without the Application class, the above program will end right after you run it. The magic in Application.Run() is that it sets up a Win32 message pump so that your whiz bang WPF objet d’art can interact with the rest of Windows, and not exit immediately. There is a surprising amount going on in those four lines of code. Let me explain the big things, before I tell you about the subtlety I found.

There can only be one Application object per process. After the first line of code in the snippet above is run, you can access the static Application.Current property. Doing a test in the Immediate window in Visual Studio to check equality of app and Application.Current will yield true. You can access this anywhere in your app, which makes it really handy.

Let’s continue with executing the second line.

Once the win instance is created, if we were to inspect the app object again, we’d see a few things have changed: the MainWindow property is now non-null — it’s pointing to the win instance; also, the Windows collection will have a Count of 1. For every other window created during the lifetime of the application, the Windows collection will be added to.

Quite a lot has happened in just two lines of code!

The other two lines are obvious; a lot happens when they execute too, but they’re peripheral to the discussion, so let’s move on.

This is a common pattern. Microsoft recognized this and codified it into a pattern. The Application class is designed to be inherited, and a WPF app that doesn’t show a window is a very boring thing. If you create a new WPF application project in VS, you don’t have to write that Main method above; it’s all done for you with code gen in the inherited Application object. You don’t even need to explicitly instantiate a Window instance: VS points the Application.StartupUri property to the XAML file defining your main window.

Now that’s great for one-off demos or simple applications that do the equivalent of turn a light on and off. But, in my experience as a Windows developer, if you want to do anything complicated, your application will have all sorts of configuration to do; or you have to log in to a service to do anything useful; or whatever. Suppose a developer had to code a scenario to show a dialog on the first run of the app to do some absolutely necessary, can’t-run-the-app-without-it configuration. To develop that scenario, one would have to eschew the StartupUri property for something slightly more complex.

The Application class also has a number of important events concerned with application lifetime. One of them is the Startup event. A naive developer would handle the previously mentioned scenario of a config dialog in that event handler, like so:

public class MyApp : Application
{
    protected override void OnStartup(object sender, StartUpEventArgs e)
    {
        if (firstRun)
        {
            MyConfigDialog dialog = new MyConfigDialog();
            if (!dialog.ShowDialog().Value)
            {
                this.Shutdown();
            }
        }
        MyMainWindow window = new MyMainWindow();
        window.Show();
    }
}

If firstRun is true, and you click OK on the dialog, so that ShowDialog() returns true, then the app will shutdown. I know what you’re thinking:

Huh?

I’m not sure, myself: this may be a bug. But here’s what’s going on: if this is the first run of the app, then the dialog is shown. It’s the first Window class created. Therefore, the Application.MainWindow property is set to the dialog instance. When ShowDialog() returns, the dialog is closed. Therefore, Application.MainWindow is null. It’s like that MyMainWindow instance is invisible or something. He could be screaming at the top of his lungs at Application: “HEY, LOOK AT ME! I’VE GOT SOMETHING TO SHOW YOU!”

Then Application just turns around and exits the building.

“ASSH– wait a minute! I’m invisible! I don’t need that stupid App instance. I’m going to rob a bank! I’ll be rich and the ladies will love me.” Then he falls on the floor lifeless, ’cause the whole process died. Poor MyMainWindow.What, you don’t anthropomorphize your objects?

You could also set the MainWindow property yourself, apparently, at any time you want to. But this fails too:

public class MyApp : Application
{
    protected override void OnStartup(object sender, StartUpEventArgs e)
    {
        if (firstRun)
        {
            MyConfigDialog dialog = new MyConfigDialog();
            if (!dialog.ShowDialog().Value)
            {
                this.Shutdown();
            }
        }
        MyMainWindow window = new MyMainWindow();
        //guess what? this doesn't work!
        this.MainWindow = window;
        window.Show();
    }
}

I’m seriously baffled by this. Looking around in Reflector, the code I’m looking at says it shouldn’t act like this. I also don’t touch Application.ShutdownMode (I’ve tested this with OnLastWindowClose and with OnMainWindowClose). Anyway, to workaround the issue, simply ensure that MainWindow is instantiated first:

public class MyApp : Application
{
    protected override void OnStartUp(object sender, StartUpEventArgs e)
    {
        //this works! 
        MainWindow window = new MainWindow();
        if (firstRun)
        {
            MyConfigDialog dialog = new MyConfigDialog();
            if (!dialog.ShowDialog().Value)
            {
                this.Shutdown();
            }
        }
        window.Show();
    }
}

The Application class is a much needed addition to Windows programming. A cross between the ASP.NET Application and Session classes and the WinForms Application class, it provides a property bag, application lifetime events, application-wide resources, an entry point, a Win32 message pump and access to the application’s windows including the Main Window. Architecturally, I find this class very appealing, but that’s a topic for another post.

Just watch out for trying to be fancy with extra windows.

Exporting Blog Posts from Subtext in BlogML

I’ve recently been asked for more detail on how I extracted my blog posts from Subtext. I hacked my solution together in a few nights of hacking. Once I got it working, I completely flushed all memory of what I did. But I was asked a whole two times, dear readers! With that overwhelming curiosity, I have no choice but to respond. For background, please read the previous post on what I did generally to convert from Subtext to WordPress.

I’m told that the BlogML export always fails in Subtext, which is the same problem I had. If I recall, it would look like it succeeded, but the XML file you got back would be empty. I was using a version that ran on .NET 1.1 (I think around 1.5, but I’m not sure), but the technique I outline below should work for Subtext 1.9.5. I’ll explain (with some code!) how I got around that and it will hopefully help some people out. I had one single-user blog running on Subtext; Multi-user may need far more attention. You will have to get your hands dirty in the code; and by the end of it, you’ll be more familiar with Subtext than you ever wanted to be. I’m writing this from memory, so take whatever I say as a guide rather than gospel. I no longer have a subtext blog set up so I can’t rerun this to see why I made the changes I made. If you’re really determined, you’ll find a way to get your data. I am willing to help anyone extract their posts from Subtext, though. Just contact me through this post, or through the contact form. Maybe we can make this a little more robust to help others.

When I first tried to export using the web interface, as I mentioned, I’d get an XML file, but it would be empty. Bummer! My first thought was that I had to figure out the right query for the database to extract all the posts. Then I would have to format all the posts into some kind of XML format to import into my new blog engine, WordPress. That’s a daunting task when you don’t deal with databases much. Luckily, I played some video games instead of bashing on and realized there was an easier way: using the BlogML exporter in Subtext!

I don’t remember exactly how I came to my solution — maybe I bombed around the code and concluded that the reason it was failing had little to do with the BlogML code? — but it worked, and this was the type of quick one-off problem to which one of my favourite sayings applied: If it’s stupid and it works, it isn’t stupid.

So here’s what I did. I created a ConsoleApplication1 project, referenced just enough of the subtext assemblies (Subtext.BlogML, Subtext.Framework and Subtext.Extensibility) to instantiate their BlogMLWriter and write out the BlogML to disk using an XmlTextWriter. Then I hacked the subtext code to make it compile and run without exceptions. Like I said last time, this solution is not pretty or perfect. To make matters worse, the subtext code I used in my hacked solution was not the same code that my blog was running, so the database versions didn’t match up. Column names had been changed or added; stored procedures had been renamed or added to. This made me do some seriously weird things like tweak stored procedures and DataReaders and I think install stored procedures that weren’t there. I did the types of things that shouldn’t really be recorded for posterity on a blog, you know?

Here’s the only code in my ConsoleApplication1 project:

class Program
{
    static void Main(string[] args)
    {            
        IBlogMLProvider provider = new Subtext.ImportExport.SubtextBlogMLProvider();

        provider.ConnectionString = "yourConnectionString";
        if (provider.GetBlogMlContext() == null)
        {
            Console.WriteLine("ERror'd");
            return;
        }
        BlogMLWriter writer = BlogMLWriter.Create(provider);

        using (XmlTextWriter xmlWriter = new XmlTextWriter("blog.xml", Encoding.UTF8))
        {
            xmlWriter.Formatting = Formatting.Indented;
            writer.Write(xmlWriter);
            xmlWriter.Flush();
        }
        Console.WriteLine("It worked?!");
    }
}

Looks pretty simple, eh? Too bad all the changes are buried deep in completely unrelated classes. I copied the subtext web.config and renamed it app.config. You have to set your connection string in two places in the config file as well as in the Program.cs file shown above (search for ‘yourConnectionString’). Also, since we’re running code written for ASP.NET in a console app, some things simply will not work, like HttpContext.Current. You’ll be shown them quickly after running the first time.

Below is an example of one of the changes I had to make:

private static SqlParameter BlogIdParam
{
    get
    {
        int blogId;
        //if (InstallationManager.IsInHostAdminDirectory)
        //    blogId = NullValue.NullInt32;
        //else
            blogId = 0;

        return DataHelper.MakeInParam("@BlogId", SqlDbType.Int, 4, DataHelper.CheckNull(blogId));
    }
}

This is in Subtext.Framework\Data\SqlDataProvider.cs. See the commented code? InstallationManager, through a number of indirections (like, I don’t know, 57; Subtext is way over-architected) uses HttpContext.Current, so I commented that out. I may have even hardcoded blogId to 0, I don’t remember.

You can download the ConsoleApplication1 project below and try it out if you wish.

Now, if you want to convert BlogML to the WordPress export format…

The Missing .NET #6: Version Tolerant Serialization

The .NET framework is huge, but not so huge that it does everything for everyone; there are things that they in Redmond miss or don’t do for whatever reason but is still generally applicable to many developers. So, dear reader, I present to you a series of posts on stuff I find missing in .NET, typically where even the Google fails to find the answer. It could be a useful class, a technique, a good practice or documentation that should be in the framework but isn’t or isn’t widely publicized. Click here for a complete list of Missing .NET entries.


I work on a .NET application that now runs on 2.0 but was written for 1.1. It’s bit like a farmer’s son who moved to the city and still does things as if he was on the farm. Like mow his two-square-meter lawn with a ride-on mower, "just like daddy used to back home." That’s fine, it gets the job done, but, dude, there’s a better way. Get a push mower, damn it.

Getting it back in the garage is a real bitch

Getting it back in the garage is a real bitch

In .NET 1.1, serialization (binary serialization, to be clear) is a bit hairy when you’re successful enough to ship multiple versions of your product and you don’t consider versioning until the first bug report about serialization problems. Changing the type, by either adding or removing fields, in .NET 1.1 causes previous versions of your type to lose their mind. The only way to deal with it at all was to implement ISerializable, which is fraught with problems, not the least of which is it makes you entirely responsible for serialization and deserialization of the whole type for ever and ever.

Now that we’re running on .NET 2.0, we have more options. Microsoft changed the behaviour so that it’s version tolerant by default – no more exceptions on new fields. But there is other awesome stuff besides, so we can have more control over the whole process.

Suppose we had the following serializable type:

//Version 1
[Serializable]
public class MyClass
{
  private string myString;

  public string MyString
  {
     get { return myString; }
     set { myString = value; }
  }
}

You ship your software. MyClass is used to great success; in fact, it made you the most successful MyClass maker in the world. For version 2, you’ve promised big things for your customers. After all the design work your new, improved MyClass becomes the following:

//Version 2
[Serializable]
public class MyClass
{
  private string myString;
  private int myInt;

  public string MyString
  {
     get { return myString; }
     set { myString = value; }
  }

  public int MyInt
  {
     get { return myInt; }
     set { myInt = value; }
  }
}

Oooh, look at all the new features!

MyClass Maker version 2 gets in to QA to test upgrading. All the MyClass version 1 instances upgrade just fine, but you had the good fortune to run on .NET 2.0, which by default doesn’t throw exceptions when there is a field for which the serialized instance does not have data. It just works; Microsoft put serialization in the Pit of Success in .NET 2.0.

But QA came back to Dev with the complaint that after upgrading the MyClass instance didn’t show off the awesomeness of the new features. They think the default value of the new field should be something else. Since you’ve just been reading up on Version Tolerant Serialization, you know just what to do.

What we need is a way to influence deserialization. With .NET 2.0, Microsoft introduced four attributes that deal with serialization process: OnSerializingAttribute, OnSerializedAttribute, OnDeserializingAttribute, OnDeserializedAttribute.

To set a default value for myInt, we create a method with a specific signature and apply the OnDeserializingAttribute to it You could also set the default where you declare the variable if all new instances have the same default, like so:

[OnDeserializing]
private void SetMyIntDefault(StreamingContext sc)
{
   myInt = 42;
}

If you implement ISerializable as well, this method is called before the deserialization constructor. Only one method per class can be marked with each of these attributes. We set the default value in the OnDeserializing method so that, if there is a myInt value in the serialized instance, the default value gets overwritten with the serialized value.

Your marketer just came back from a conference. He really likes this social aspect to these new-fangled web 2.0 applications. Now you’re required to enable sharing of MyClass instances among users. Trouble is, we can’t guarantee everyone is using the most up-to-date version and marketing won’t let us force upgrades. It’s OK, we can deal with that. We just have to tweak our new MyClass version; we’ll mark the myInt field declaration with the OptionalFieldAttribute, so that the serializer will know not to explode if it’s not there. I’m not sure whether this is necessary because during my testing for this article, the presence or absence of OptionalField didn’t seem to matter. But it could be because I was lazy: I didn’t test from 1.1 to 2.0.

[Serializable]
public class MyClass
{
   private string myString;
   [OptionalField(VersionAdded=2)]
   private int myInt;

   public string MyString
   {
      get { return myString; }
      set { myString = value; }
   }

   public int MyInt
   {
      get { return myInt; }
      set { myInt = value; }
   }

   [OnDeserializing]
   private void SetMyIntDefault(StreamingContext sc)
   {
      myInt = 42;
   }
}

Because I’m a good little developer that reads documentation, I included the VersionAdded property in my OptionalField declaration. This is for "future compatibility with new serializers in the framework." I’m not sure there will be other serializers in the framework since the CLR hasn’t changed since 2.0, as well as the whole confusing red bits/green bits thing. But you know what assuming does, right? So I put it in.

One thing I tried in my experimentation was the following: suppose you have a ton of types that implement ISerializable because they’re legacy 1.1 types. As long as you keep the convention of your keys being the same as the name of the field, then you can move the ISerializable implementation to the dustbin. It seems to just work, although I’d test it a little more thoroughly. Suppose MyClass version 1 looked like the below code. In Version 2, you could delete the ISerializable stuff.

[Serializable]
public class MyClass : ISerializable
{
   private string myString;

   public MyClass()
   {
   }

   protected MyClass(SerializationInfo info, StreamingContext context)
   {
      myString = info.GetString("myString");
   }

   public string MyString
   {
      get { return myString; }
      set { myString = value; }
   }

   public void GetObjectData(SerializationInfo info, StreamingContext context)
   {
      info.AddValue("myString", myString);
   }
}

Deleting code you don’t need anymore feels so good. Release yourself from the bonds of ISerializable!

There are so many unsung improvements in the BCL in .NET 2.0 that I’m still finding them nearly four years later. The above improvements to serialization move it from cumbersome chore fraught with peril to those who dare master it to the magic of "it just works." Serialization code is hard to get right, so I’m glad Microsoft took most of the onerous stuff off our hands. I’d encourage you to take a look at the MSDN article on Version Tolerant Serialization for all the details on this stuff. I’ll leave this article with their recommended practices for creating serializable types.

To ensure proper versioning behavior, follow these rules when modifying a type from version to version:

  • Never remove a serialized field.

  • Never apply the NonSerializedAttribute attribute to a field if the attribute was not applied to the field in the previous version.

  • Never change the name or the type of a serialized field.

  • When adding a new serialized field, apply the OptionalFieldAttribute attribute.

  • When removing a NonSerializedAttribute attribute from a field (that was not serializable in a previous version), apply the OptionalFieldAttribute attribute.

  • For all optional fields, set meaningful defaults using the serialization callbacks unless 0 or null as defaults are acceptable.

To ensure that a type will be compatible with future serialization engines, follow these guidelines:

  • Always set the VersionAdded property on the OptionalFieldAttribute attribute correctly.

  • Avoid branched versioning.

Well, actually, let me leave by adding one more: Don’t implement ISerializable when introducing new types on a .NET 2.0 or greater project. If you can’t serialize your types with the above attributes, you’re doing it wrong.

The Missing .NET #5: Tracepoints

The .NET framework is huge, but not so huge that it does everything for everyone; there are things that they in Redmond miss or don’t do for whatever reason but is still generally applicable to many developers. So, dear reader, I present to you a series of posts on stuff I find missing in .NET, typically where even the Google fails to find the answer. It could be a useful class, a technique, a good practice or documentation that should be in the framework but isn’t or isn’t widely publicized. Click here for a complete list of Missing .NET entries.


Lately, I’ve been debugging windowing code often. Windowing code is stuff like window sizing, resizing, painting, etc.; code that has something to do with drawing the window. Debugging that code used to be fairly arduous because anytime you stepped into your method, looked around, then started execution again, the windowing code would need to be re-run because you had Visual Studio focused and not your app; since you have a breakpoint in the windowing code, Visual Studio would break into your method which you probably didn’t want this time because you were already there, so you hit F5 again to continue execution and start the cycle over.

Do that for 10 minutes and you soon wise up; you strew print statements all over the place to get at the data you want to debug, figure out what you’re doing wrong, stop, fix, run and repeat. Once you’ve fixed your bug, then you delete the print statements if you’re not totally pressed for time, in which case, all kinds of debugging code just hangs around there forever and ever for everybody to ignore until someone comes around to delete it. Then, and only then, another drawing bug comes in starting the whole process all over again. Wouldn’t it be awesome if there was a way to break into a method to see the data without breaking in and without all those print statements? Fortunately, Microsoft thought that this scenario was painful enough that they put this feature in. It’s called Tracepoints; it’s been around since Visual Studio 2005.

We’re doing something a little different in this Missing .NET edition: highlighting something that is in the framework (well, peripheral to it, technically, but isn’t VS synonymous to .NET in everyone’s mind?), but that most people probably don’t know about, but should because it’s so useful.

I find this feature useful for the above scenario but also for bug source hunting. It’s a great way to find the source of an issue without breaking into the code and stepping into everything.

To setup a tracepoint, there are, of course, many ways to do it. My favourite is to create a breakpoint by clicking in the margin on the right of the code window, then right-clicking and choosing When Hit…

Setting up a tracepoint: right-click on a breakpoint and select When Hit...

You’re presented with the following dialog:

tracepointdialog

The dialog pretty much says it all.

I always choose Print a message and delete the default. The $FUNCTION keyword prints the whole method name including namespace and parameter types which is a little too talky for me. I write out the method name, typically, and then any variables I’m interested in.

For example, the last bug fix was in a SizeChanged event handler that I traced with the following: "mainMenu_SizeChanged: {Size}, {RestoreBounds.Size}"

This prints out the Size and RestoreBounds.Size properties of the Window class in which I’m tracing.

For more on breakpoints and tracepoints, check out the MSDN documentation here.

Got any tips for using the debugger?