Question

今天偶然发现了这个，我找不到任何有关它的信息。所以这就是我在这里问的原因。也许有人知道为什么。

我在web.config中添加了自定义WCF行为扩展。它看起来像这样：

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

（那里没有空格：MyNs.TracingErrorBehaviorElement,MyNs）

它在我的开发机器，我们的登台服务器，我们的实时服务器等上运行得非常好。

今天我们在客户服务器上安装了该产品，并得到以下例外：

System.Configuration.ConfigurationErrorsException：发生错误为。创建配置节处理程序 system.serviceModel / behavior：扩展元素'errorBehavior' 无法添加到此元素。验证扩展名是否正确在扩展集合中注册 system.serviceModel /扩展/ behaviorExtensions ...

花了半个小时在网上搜索可能的原因后，我在全限定程序集名称中添加了空格。所以我把它改成了：

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

（见空格：MyNs.TracingErrorBehaviorElement, MyNs）

并且有效。

有谁知道为什么它在某些机器上没有空间而不在其他机器上工作？我检查了.Net-versions。他们匹配。它可能是由区域设置造成的吗？

编辑说：

我检查了所有机器上使用过的.Net版本，它们都是一样的：.Net 4.0 但我发现我得到错误的机器与缺少的空白和其他机器的工作区别：所有没有空白的工作机器都安装了.Net Framework 4.5。所以它可能是4.0中修复并用4.5部署的那些错误之一，对吧？

Answer 1

这是一个已知的错误，由Shawn Cicoria在this blog post中记录。

它没有说明错误修复的确切时间，WCF配置类完全过于复杂，无法缩小范围。考虑到帖子的年龄，我猜测这是一个.NET 4.5修复程序。由于安装了4.0，因此客户端站点出现故障。您从为项目挑选的目标中了解得更清楚。

否则很好地证明微软修复错误是多么困难。

Answer 2

嗯，MSDN说：

空格与所有类型名称组件相关，但程序集名称除外。在程序集名称中，'，'分隔符之前的空格是相关的，但'，'分隔符之后的空格将被忽略。

实际上，测试表明事实确实如此 - GetType和其他类型解析方法确实在 ,分隔符之后忽略空格。

然而，WCF以某种方式使这一点复杂化，因为它实际上需要完全限定的类型名称完全是由于某种原因从Type.AssemblyQualifiedName得到的值。也许它在某处保留了类型的缓存，我不知道。

至于为什么这只发生在某些机器上，我会把我的赌注放在GAC或其他略微修改装配/类型分辨率的系统上。由于您没有使用snk，GAC是不可能的，但也许有一些配置可以为您更改此设置，可能在machine.config中，或者它在IIS配置中的Web应用程序中。

这似乎是.NET 3.5中的配置错误。 .NET 4.0+没有相同的问题。您确定该应用程序运行的是相同版本的.NET吗？如果您正在使用Web应用程序（客户的服务器可能很好地配置为使用.NET 3.5），这很可能是不同的，事实上，您必须指定system.web.compilation[targetFramework]和httpRuntime定位正确的框架版本。我会添加一个指向该bug的链接，但是虽然它在很多地方被引用，但该文章似乎已从MS Connect中删除了:)

为什么完全限定的程序集名称有时需要空格？

2 个答案: