Keyvan Nayyeri

One of the very weird and not acceptable issues that you may face with during your development with Windows Communication Foundation is what I'm going to write about it here.

There is no doubt that you need to do some customizations in WCF for in-depth scenarios and one of the cases may be extending behaviors with custom behavior extensions.

Developing a custom behavior extension is a separate topic for its own but there is a very weird issue in configuration for a custom behavior extension.

You configure a WCF service for custom behavior extensions by adding a new element to sub-element located inside element within . Here all you need to do is choosing a name and setting the type for the behavior extension. Later you need to use this custom behavior in your configuration file.

Here is a sample configuration for such an extension:

Now if you try to get access to this service with this configuration then you should get a configuration error like this:

Here is the error description:

An error occurred creating the configuration section handler for system.serviceModel/behaviors: Extension element 'customHttpBehavior' cannot be added to this element.  Verify that the extension is registered in the extension collection at system.serviceModel/extensions/behaviorExtensions.

This configuration error occurs whenever .NET runtime tries to parse your configuration and reaches to a custom behavior element that is defined by your extension and references it. As .NET is unable to load your behavior extension (due to the error that I describe) then it is unable to find your element and throws this configuration exception.

Now what's the reason? The reason is very bad for a product in this level (and many other guys have confirmed that). Mitch Denny has an excellent write up on this and there is a Microsoft Connect feedback item that reports this to MSFT. You can reach Mitch's post about the internal reasons to see this weird behavior from WCF and test it yourself.

In short, I would say that WCF has a built-in issue that doesn't let it load your assembly with the above definition (just by pointing to the type name and assembly name). Instead, you need to use the fully qualified name of your assembly and this will solve the issue for you.

So with something like the below configuration, you should be able to go on:

I hope that Microsoft solves this in the first service pack. Fortunately I was sure about the correctness of my code and configuration and quickly jumped into Google to search for the issue but as some people have written already, this may take a lot of time from someone who thinks that this is a problem with his or her code.