Search code examples
c#.netfully-qualified-naming

Why do fully qualified assembly names sometimes require spaces?

Just stumbled over this one today and I can't find any information about it. So that's why I ask here. Perhaps someone knows why.

I added a custom WCF behavior extension to my web.config. It looks like this:

<behaviorExtensions>
    <add name="errorBehavior" type="MyNs.TracingErrorBehaviorElement,MyNs, 
         Version=1.0.6.0, Culture=neutral, PublicKeyToken=null" />
</behaviorExtensions>

(No space in there: MyNs.TracingErrorBehaviorElement,MyNs)

It works perfectly fine on my development machine, on our staging server, on our live server, etc.

Today we installed the product on a customer server and got the following exception:

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

After spending half an hour searching the web for possible causes I added spaces to the fully qualified assembly name. So I changed it to:

<behaviorExtensions>
    <add name="errorBehavior" type="MyNs.TracingErrorBehaviorElement, MyNs, 
         Version=1.0.6.0, Culture=neutral, PublicKeyToken=null" />
</behaviorExtensions>

(See the space: MyNs.TracingErrorBehaviorElement, MyNs)

and it worked.

Does anyone know why it works without a space on some machines and not on others? I checked the .Net-versions. They matched. Could it be caused by regional settings?

Edit says:

I checked the used .Net versions on all machines and they are all the same: .Net 4.0 But I found a difference between the machine where I get the error with a missing blank and the others machines where it works: All machines where it works without the blank have installed .Net Framework 4.5. So it could be one of those bugs that were fixed in 4.0 and deployed with 4.5, right?

Solution

  • This is a known bug, documented in this blog post by Shawn Cicoria.

    It doesn't say anything about exactly when the bug got fixed, the WCF config classes are entirely too convoluted to narrow it down. I'd guess, given the age of the post, that this is a .NET 4.5 fix. With failure on the client site due to it having 4.0 installed. You'd know better from the target you picked for your project.

    Otherwise a good demonstration how difficult it is for Microsoft to ever fix bugs.