技术开发 频道

解读WCF的一个非常“无语”的BUG!

  现在我们通过IE直接访问服务的地址,你会看到如下的界面——这基本上可以表面我们的服务被成功发布。

1
 

  现在我们做一个非常微小的改变,将扩展行为类型从"Artech.Bug4BehaviorExtension.FooBehaviorElement, Artech.Bug4BehaviorExtension” 改成“Artech.Bug4BehaviorExtension.FooBehaviorElement,Artech.Bug4BehaviorExtension”。可能你都没有注意到到底我做了怎样的改动,提醒你一下:我们将类型名称和程序基名称之间的空格去掉了。

<?xml version="1.0" encoding="utf-8" ?>  
<configuration>  
    
<system.serviceModel>  
        
<behaviors>  
            
<serviceBehaviors>  
                
<behavior name="myServiceBehavior">  
                    
<foo/>  
                    
<serviceMetadata httpGetEnabled="true"/>  
                
</behavior>  
            
</serviceBehaviors>  
        
</behaviors>  
        
<extensions>  
            
<behaviorExtensions>  
                
<add name="foo" type="Artech.Bug4BehaviorExtension.FooBehaviorElement,Artech.Bug4BehaviorExtension" />  
            
</behaviorExtensions>           </extensions>  
        
<services>  
            
<service behaviorConfiguration="myServiceBehavior" name="Artech.Bug4BehaviorExtension.CalculatorService">  
                
<endpoint binding="ws2007HttpBinding" contract="Artech.Bug4BehaviorExtension.ICalculator" />  
                
<host>  
                    
<baseAddresses>  
                        
<add baseAddress="http://127.0.0.1:3721/calculatorservice" />  
                    
</baseAddresses>  
                
</host>  
            
</service>  
        
</services>  
    
</system.serviceModel>  
</configuration>

 

  现在再次刷新IE页面,你将会得到如下的结果。页面上的错误信息表明:我们定义的行为扩展类型无法被WCF解析——仅仅删除了一个小小的空格,WCF就不能正确地解析类型,这彻底让我无语。在本章的开篇我已经说过,这个问题我在很多年前就遇到过。因为我习惯于手工进行WCF的配置,在进行WCF扩展相关配置的时候,我经常发现我的服务访问不了,但是怎么也找不到问题的症结。然后通过VS提供的配置工具去配置,发现服务可以正常访问。然后两者进行对比,也没有发现有什么差异。其实在那种情况下,即使我发现多一个空格这种差异,我也不会觉得这种差别就是问题的症结所在。隐约记得有位读者在我的Blog上有过相关的留言,当时也没有在意,所以这个问题就一直没有深究。我想肯定会有人之前就发现过这个问题,肯定还会有后继者会遇到这个问题。为此,写下了这篇没有什么技术含量的博文,希望遇到相似问题但百思不得其解的人能够发现这篇文章。

1
 

0
相关文章