Why do fully qualified assembly names sometimes require spaces?

Question

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?

http://blogs.msdn.com/b/scicoria/archive/2010/06/10/spaces-in-type-attribute-for-behavior-extension-configuration-issues.aspx — Hans Passant, Mar 12 '14 at 11:34

score 5 · Accepted Answer · answered Mar 12 '14 at 11:54

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.

score 3 · Answer 2 · answered Mar 12 '14 at 09:31

Well, the MSDN says:

Spaces are relevant in all type name components except the assembly name. In the assembly name, spaces before the ',' separator are relevant, but spaces after the ',' separator are ignored.

Indeed, testing indicates that this is in fact the case - GetType and other type resolution methods really do ignore spaces after the , separator.

However, WCF complicates this somehow, because it actually requires the fully qualified type name to exactly be the value you get from Type.AssemblyQualifiedName for some reason. Perhaps it keeps a cache of types somewhere, I don't know.

As for why this only happens on some machines, I'd put my bet on either the GAC or some other system that slightly modifies assembly / type resolution. Since you're not using a snk, GAC is out of the question, but perhaps there's some configuration that changes this for you, maybe in the machine.config or if it's in a web application in IIS configuration.

It seems that this is a configuration bug in .NET 3.5. .NET 4.0+ doesn't have the same issue. Are you sure the application is running the same version of .NET? This can very well be the difference if you're working with a web application (the customer's server might very well be configured to use .NET 3.5, in fact, you should have to specify system.web.compilation[targetFramework] and httpRuntime to target the correct framework version. I'd add a link to the bug, but while it's referenced in a lot of places, the article seems to have been removed from MS Connect since :)

Thanks for your input. I edited my answer and added the .Net version information to it. So although running with the same .Net version there is the difference of installed versions on those machines. Could it be a bug that was "silently" fixed in 4.5 and included into version 4.0 running with installed 4.5? If I could mark 2 answers I would since this one is also a reasonalbe answer ;) — CrazyChief, Mar 12 '14 at 14:17
@CrazyChief The funny (not really) thing about .NET 4.5 is that it isn't a separate .NET version. It overwrites 4.0. So even if you're targetting 4.0 in your project, as soon as you install 4.5, you're no longer running on 4.0 (this is especially annoying when trying to debug memory dumps, because 4.5 introduced a breaking change to the debugging interfaces). So yeah, if it's true that the fix is only in 4.5, this would explain the mystery quite nicely :) — Luaan, Mar 12 '14 at 15:25

Why do fully qualified assembly names sometimes require spaces?

2 Answers2