Dutton's blog

Moved host

Moving my blog's hosting onto Azure over the Bank Holiday weekend, if you're reading this then it's succeeded, if you spot anything strange then please let me know in a comment.


Update 30/05/2013

Azure move is complete, but the old hosting is still up. From my visitor stats data, it looks like the nameserver change is taking a while to propagate, so if you're not reading this, it hasn't reached you yet, but then I guess you wouldn't know... so....

Anyway, I'll crack on with posting new content here, and I'm sure you'll all catch up soon.

Update 2 30/05/2013

I have figured out why my visitor stats are so low; the old permalinks which took you straight to specific posts had been broken so the google search results and any links posted to forums were returning a 404. A side effect of moving from a linux to a windows based host is that IIS was putting index.php into the url that it was expecting. Thanks to Webloggerz for their excellent tutorial on how to fix this.

How to access the System.ServiceModel app.config configuration section in code

The app I'm currently working on is a graphical client which connects to a server for its data. This connection is made using WCF and configured within my app.config file like this:


I now need to allow the client to connect to different servers at the request of the user, so I can add these to my app.config as additional endpoint elements, like this:


The problem is, how can I access these configuration elements in code to populate a pull-down or something to let the user pick? The usual ConfigurationManager I'd use to access stuff from my app.config doesn't provide any of the ServiceModel elements so instead I had to first get the Configuration object for the application using ConfigurationManager then get to the service model section using ServiceModelSectionGroup's GetSectionGroup method, like this:

var appConfig = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
var serviceModel = ServiceModelSectionGroup.GetSectionGroup(appConfig);
var clientEndpoints = serviceModel.Client.Endpoints;
foreach (ChannelEndpointElement endpoint in clientEndpoints)
Hosting outage today

It appears that my web host, site5, has experienced some issues today, so apologies for anyone getting 404 or database errors when visiting.

I've been assured it's back to normal now.

How to allow Prism Unity modules to properly Dispose() on Application shutdown

I have a Prism application which uses a Unity DI container to load a bunch of modules which represent various elements of my application.

I recently needed to perform some clean-up in one of my modules when the application exits. Normally this is something I would do with an IDisposable implementation, but in a Prism/Unity setup Dispose never gets hit on the module code.

Here's how I got around it:

First I created a custom Event to allow me to signal my modules that the container is closing:

public class ApplicationExitEvent : CompositePresentationEvent<string> { }

Then in my bootstrapper I implement IDisposable and fire the event in my Dispose() method:

public void Dispose()
  var eventAggregator = Container.Resolve<IEventAggregator>();
  if (eventAggregator != null)

Then in my module's Initialize() method I subscribe to this event:

EventAggregator.GetEvent<ApplicationExitEvent>().Subscribe((o) => Dispose(), true);

And put whatever cleanup code I need in my module's Dispose method. Done!

How to uniquely identify an object when debugging C# in Visual Studio

Many years ago I used to develop applications in C++ under Visual Studio and despite thoroughly loving the move to managed code, in particular C# .Net I do find that I occasionally miss some of the ways I used to be able to debug old non-managed programming languages.

One thing in particular I miss when trying to fix a frustratingly elusive bug (normally involving threads or some other equally non-determinstic nightmare ;) ) is the ability to see the memory address of a particular object instance on the heap under the debugger and compare that to an instance where it appears elsewhere in my execution to be sure that they are the same.

Up to now I have just written that off as one of those managed code limitations and worked around it. That was until a colleague (cheers Dan) pointed out something that's been under my nose this whole time, this:

Make Object ID

In the Locals or Watch windows when debugging, you can right-click on any reference type and "Make Object ID" which will append a number (followed by a '#' surrounded by curly braces) to the end of the value like this:

Object ID

This will uniquely identify the object until you either right-click again and select "Delete Object ID" or stop debugging.

And here's its MSDN description (under Managed Object Identity).

I swear I really should RTFM when it comes to Visual Studio. I hoped that this was something new in VS2012 but I fired up an old VS2010 project and there it is again! It's been under my nose this whole time!