Author: Rich Slaughter

XML Deserialization InvalidOperationException

Posted on by Rich Slaughter

Just a quick one today...

I was asked to help debug an issue with XMLSerialization in .Net where the object graph would serialize fine, but on being deserialized a InvalidOperationException was being thrown.

The class that caused the problem was defined in the following way:


public Class MyClass
{
public int MyInt { get; set; }
public DateTime MyDateTime { get; set; }

public MyClass(DateTime aDateTime)
{
MyDateTime = aDateTime;
}
}

This was nested inside another class in a collection, which initially I thought could be something to do with the problem. It turned out however that in order for deserialization from XML to work, each class that is to be deserialized must have a default constructor so that an instance of the class can be created by the XML deserializer.

This is easy to forget as the C# compiler implicitly adds a default constructor when there are no constructors in a class, but as soon as you add a non-default constructor, this goes away.

Simply adding


public MyClass(){}

Was enough to solve the problem.

The binary formatter does not suffer from this problem, although classes must be marked with the [Serializable] attribute.

ASP .Net Sessions And The Idle Worker Timeout

Posted on by Rich Slaughter

I've been dealing with the realm of an ASP .Net application recently, and one of the requirements was that the session state should last for up to 60 minutes, which sounded straight forward enough, just whack the following in web.config:





Which works fine in theory, however after leaving the site idle for 20 minutes, the session state suddenly goes away.

After much hair pulling, I finally stumbled accross the Idle Process setting in IIS under the Application Pool configured for the website.

By default this is set to 20 minutes, and as the default Session State is in-process, it gets wiped when the worker process is recycled. On a deployed website this probably wouldn't be an issue as regular requests will keep the process alive, however in a single user testing environment this can obviously cause a problem when trying to test a session timeout greater than 20 minutes.

So there are two solutions to this:
1) Increase the Idle Process timeout setting
2) Use an out of process Session State (StateServer or SQLServer)

The second option simply requires that anything stored in the state be serialisable, and that you enable the ASP .Net StateServer process, although there is a slight cost as the objects have to be serialised and deserialised for each request.

For now I've simply increased the Idle Process timeout setting, however it's definately worth looking at using an out of process Session State as the Worker Process will still be restarted occasionally (Although also configurable) to ensure the health of the web server.

Not sure I totally agree with the approach of reliability through restarts, but I guess it's at least somewhat foolproof.

Concise Invoking into the UI Thread

Posted on by Rich Slaughter

It's a new year (and has been for a while), so time to get on and actually make use of this blog.

I often find myself having to Invoke execution back in to the UI thread, and thus far the most concise way I have come accross for doing this is as follows:

public void UIFunction(string aMessage)
{
MethodInvoker del = delegate{
lblUILabel.Text = aMessage;
};
Invoke(del);
}

This is nice as it gives you access to the function parameters inside the Invoked anonymous delegate without needing to add them to the invoke call, and also saves you from creating any more functions, whose only purpose is to deal with being invoked.

Obviously you may want to consider that anyway if the logic is complex, but I like that this method keeps things nicely encapsulated in a single function.

The MethodInvoker delegate comes from the Windows.Forms namespace, so if you want to use this method where it is unavailable, such as on the Compact Framework, simply create a new delegate type as follows:
public Delegate void MethodInvoker();

Unit Testing A Threaded Service Class

Posted on by Rich Slaughter

Having become intrigued by Test Driven Development, I've spent a good deal of time getting to grips with the tools and techniques, but find I'm still coming accross scenarios that leave me wondering, "How on earth do I test this?".

One of the biggest areas that's given me grief is multi-threading. I spent some of today trying to decide the best way to test a worker class that does its work in a secondary thread and returns its completion status asynchronously.

The application structure generally looks like this:

MainForm <-> App <-> Worker Class

The GUI may invoke the  Worker Class to do some work that takes a significant amount of time, so this is obviously threaded.

This forms a pretty standard MVC structure, so my initial plan was to use the MVC structure to feed back completion status through the App as would happen in a standard MVC model, treating the app as the controller, without the use of any events. I didn't want to make use of an event here as I felt it would be introducing additional complexity when deciding where the event should be hooked and so on.

Whilst this felt like the simplest approach, it fell flat on not being very testable.

Making it Testable

In order to test the worker service the App is replaced with a mock object, which is fine for checking that the completion method is called, but fails in that it could not be monitored to see when the worker thread has finished.

A stop gap solution involved entering a while loop for 10 seconds until I was sure the thread was complete, before letting the test continue and validate that all the mocks we succesfully met.

Obviously this reeks, so I started looking at ways of exposing the worker thread so that I could monitor it directly, before realising that this was also leading me down the wrong path, as ideally the test shouldn't care about the internals of what is being tested.

Had I gone down that road, it would most likely have led to problems when trying to test what happens when it is fired multiple times for example.

Having decided that, I relented and did what I was initially trying to avoid, and made use of an event for the completion of the work, as is documented in a number of places as the correct way to test worker threads.

It turns out this made the most sense as the App is responsible for creating the Worker Class in the first place, so is the perfect place to register for the completion event, so that it can then be passed to the UI in the same way that it was before, so the GUI encapsulation is still well maintained (Assuming an interface is used).

This can then be tested by using an anonymous delegate to signal when the waiting should be end, and I no longer have to do any nasty waiting for an arbitrary length of time!

Windows Mobile Proxy Ports

Posted on by Rich Slaughter

I recently had the need to direct some traffic to a Windows Mobile device connected over Activesync, and my initial investigations turned up the fact that the device will get the ip 169.254.2.2 or 192.16.55.100 when docked.

However, if you try to communicate to these IP addresses directly, you will discover that no traffic gets through.

To work around this limitation, you need to make use of ProxyPorts, which forward ports to a mobile device connected over Activesync (or WMDC under Vista).

Setting this up, simply entails pointing your favorite registry editor at the key:
\HKLM\Software\Microsoft\Windows CE Services\ProxyPorts

Make a new DWORD entry with a descriptive name and the port number you wish to have forwarded to the device. You will then be able to communicate with your device on that port by directing some comms traffic at 127.0.0.1 on the destop PC.