现在我们通过IE直接访问服务的地址，你会看到如下的界面——这基本上可以表面我们的服务被成功发布。
现在我们做一个非常微小的改变，将扩展行为类型从"Artech.Bug4BehaviorExtension.FooBehaviorElement, Artech.Bug4BehaviorExtension” 改成“Artech.Bug4BehaviorExtension.FooBehaviorElement,Artech.Bug4BehaviorExtension”。可能你都没有注意到到底我做了怎样的改动，提醒你一下：我们将类型名称和程序基名称之间的空格去掉了。
1: <?xml version="1.0" encoding="utf-8" ?> 2: <configuration> 3: <system.serviceModel> 4: <behaviors> 5: <serviceBehaviors> 6: <behavior name="myServiceBehavior"> 7: <foo/> 8: <serviceMetadata httpGetEnabled="true"/> 9: </behavior> 10: </serviceBehaviors> 11: </behaviors> 12: <extensions> 13: <behaviorExtensions> 14: <add name="foo" type="Artech.Bug4BehaviorExtension.FooBehaviorElement,Artech.Bug4BehaviorExtension" /> 15: </behaviorExtensions> 16: </extensions> 17: <services> 18: <service behaviorConfiguration="myServiceBehavior" name="Artech.Bug4BehaviorExtension.CalculatorService"> 19: <endpoint binding="ws2007HttpBinding" contract="Artech.Bug4BehaviorExtension.ICalculator" /> 20: <host> 21: <baseAddresses> 22: <add baseAddress="http://127.0.0.1:3721/calculatorservice" /> 23: </baseAddresses> 24: </host> 25: </service> 26: </services> 27: </system.serviceModel> 28: </configuration> |
|
现在再次刷新IE页面，你将会得到如下的结果。页面上的错误信息表明：我们定义的行为扩展类型无法被WCF解析——仅仅删除了一个小小的空格，WCF就不能正确地解析类型，这彻底让我无语。在本章的开篇我已经说过，这个问题我在很多年前就遇到过。因为我习惯于手工进行WCF的配置，在进行WCF扩展相关配置的时候，我经常发现我的服务访问不了，但是怎么也找不到问题的症结。然后通过VS提供的配置工具去配置，发现服务可以正常访问。然后两者进行对比，也没有发现有什么差异。其实在那种情况下，即使我发现多一个空格这种差异，我也不会觉得这种差别就是问题的症结所在。隐约记得有位读者在我的Blog上有过相关的留言，当时也没有在意，所以这个问题就一直没有深究。我想肯定会有人之前就发现过这个问题，肯定还会有后继者会遇到这个问题。为此，写下了这篇没有什么技术含量的博文，希望遇到相似问题但百思不得其解的人能够发现这篇文章。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
