Are you developing an extension to Windows Communication Foundation (for example a behavior or message encoder) with configuration file support? If you are you may be getting frustraited by an exception something like the following (the precise nature depends on the kind of extension you are developing).
I was, and the frustraiting thing was that I had built some of these in the past for various purposes without any issues so I had a real tough time figuring out what the hell was going on. Well it turns out that it is a string comparison issue. Lets take a look at the configuration file for a WCF service:
In this configuration file I have a simple math service but I have applied an endpoint behavior to it called “beep†in the configuration file. This is a custom behavior so I’ve had to implement my own BehaviorExtensionElement and in this case I’ve implemented the element and the actual IEndpointBehavior in the same class (because I can). What happens is when WCF initialises it loads in the list of the extensions into a hashtable (simplication – there is a lot more code involved than just a hashtable-like data structure) – so in this case “beep†is mapped to “ServerApplication.BeepBehavior….â€, at the same time an instance of the class specified in the second value is instansiated and stored.
As execution continues and the service host is brought online the <beep /> element is encounted. The aforementioned hashtable is looked up and the fully qualified class name is retreived. This is then used as a key to find the custom BehaviorExtensionElement and this is where it comes unstuck. When the BehaviorExtensionElement is stored it is indexed with the fully qualified type name which is fetched using .GetType(), when this value is rendered as a string it looks like this:
ServerApplication.BeepBehavior, ServerApplication, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
Notice the spaces between each of the type name elements. Now – compare this to the screenshot of the configuration file above. As you can see there is no space between the type name elements. Since the lookup is based on a simple string comparison the space is significant and the WCF runtime can’t find the previously created BehaviorExtensionElement instance and it all falls in a heap – if you go and put the spaces in it works perfectly.
The frustraiting thing is that the space sensitivity of the type attribute in the WCF portions of the configuration files is completely at odds with the norms in the rest of the .NET Framework (although I am aware of some similar issues in WPF thanks to Darren). Unfortunately it looks like Tomas Restrepo found the issue as well in this feedback entry on Microsoft Connect – but it looks like all development was closed off and it obviously shipped with this quirk.
Personally I think that this needs to be treated as a bug and fixed as soon as possible because it is going to drive developers who try to extend WCF completely nuts and when they realise what the problem was the WCF team better hope they are no where within reach. Given it isn’t a critical bug I suspect that it may have to wait for a service pack to be issued though.