博客园_shenba

WCF中容易忽视的ConfigurationName属性

2012-02-04T03:11:00Z

在使用WCF服务时，通常都是用svcutil生成代理类和配置，用生成的默认配置就可以调用服务。先来看看生成的默认的配置内容：

其中contract就是代理类中指向接口或契约类，假如contract的定义如下，那么默认情况下是contract接口的名字

1 [System.ServiceModel.ServiceContract]
2 public interface IService1
3 {
4 }

但实际上存在多个服务或者需要用命名空间去标记contract时，需要修改客户端配置中endpoint的中contract的名字，需要其包含命名空间，比如改成如下：

contract="ConfigNameService.IService1"。

按通常的理解，以为系统会按照类型名称去找代理类中的接口，但实际上并非这样，仅仅在执行以下代码时就会提示找不到默认终结点的错误。

1  using (var client = new Service1Client())
2             {
3                 Console.WriteLine(client.GetData(1));
4             }

而将contract的值改回"IService1"即可正常调用。

原因是代理类中的contract定义时设置的ConfigurationName决定了配置时需要配置的值，这个属性很容易被忽视，尤其是通过svcutil生成的代理类，比如以下代码：

1 [System.ServiceModel.ServiceContractAttribute(ConfigurationName="IService1")]
2 public interface IService1
3 {
4
5     [System.ServiceModel.OperationContractAttribute(Action="http://tempuri.org/IService1/GetData", ReplyAction="http://tempuri.org/IService1/GetDataResponse")]
6     string GetData(int value);
7
8     [System.ServiceModel.OperationContractAttribute(Action="http://tempuri.org/IService1/GetDataUsingDataContract", ReplyAction="http://tempuri.org/IService1/GetDataUsingDataContractResponse")]
9     ConfigNameService.CompositeType GetDataUsingDataContract(ConfigNameService.CompositeType composite);
10 }

ConfigurationName就是原服务接口的名字，因此需要手动修改ConfigurationName为需要的值，这里只能改客户代理类中的接口定义的ConfigurationName。然后在配置endpoint时的contract的值跟ConfigurationName的值保持一致即可。

本文链接

解决MVC中JSON字符长度超出限制的异常

2012-02-03T06:38:00Z

今日碰到了这么一个异常，异常信息如下：

Type : System.InvalidOperationException, mscorlib, Version=2.0.0.0,

Culture=neutral, PublicKeyToken=b77a5c561934e089

Message : 使用 JSON JavaScriptSerializer 进行序列化或反序列化时出错。字符串

的长度超过了为 maxJsonLength 属性设置的值。

Source : System.Web.Extensions

Help link :

Data : System.Collections.ListDictionaryInternal

TargetSite : Void Serialize(System.Object, System.Text.StringBuilder,

SerializationFormat)

Stack Trace : 在

System.Web.Script.Serialization.JavaScriptSerializer.Serialize(Object obj,

StringBuilder output, SerializationFormat serializationFormat)

在 System.Web.Script.Serialization.JavaScriptSerializer.Serialize(Object

obj, SerializationFormat serializationFormat)

在 System.Web.Script.Serialization.JavaScriptSerializer.Serialize(Object

这个异常是在执行MVC中的JsonResult的时抛出的，根据异常的Message得知是序列化的字符串超出了maxJsonLength的限制。并得知这个属性是由JavaScriptSerializer提供的，因为MVC内置的JsonResult是用JavaScriptSerializer进行序列化的。在网上快速搜索了一下，碰到这个问题的童鞋不少，大部分推荐的解决的方法都是在web.config中加入以下配置，设置maxJsonLength的长度即可。

<system.web.extensions>
       <scripting>
           <webServices>
               <jsonSerialization maxJsonLength="20971520"/>
           </webServices>
       </scripting>
   </system.web.extensions>

在自动提示下，很顺畅的加上了几行代码，以为这是个简洁的解决方案，但是运行网站之后报以下错误：

分析器错误消息: 无法识别的配置节 system.web.extensions。
这似乎又是碰到了一家人不认识的情况，既然无法识别为什么能带智能感知的方式输出，而且是已system.web开头的，按道理不会识别不出的。以为是拼写错误，经过进一步搜索之后，原来是缺乏了声明，加上对节点的声明即可（很大一串的内容）。

加入了声明之后，运行正常，但是问题依旧还在，而且不管maxJsonLength设置成多大都无效，就算改成1个字符，居然还能跑起来。碰到这个问题只能进一步的搜索。在这篇文章中找到了原委http://weblogs.asp.net/rashid/archive/2009/03/23/submitting-my-first-bug-after-asp-net-mvc-1-0-rtm-release.aspx。

原来MVC框架内置的JsonResult代码中，在使用JavaScriptSerializer时，都是采用的默认值，没有从maxJsonLength读取值，即忽略了这个配置。要想使用配置中的值，只能自定义一个JsonResult，重写原JsonResult的ExecuteResult方法，于是定义一个ConfigurableJsonResult，代码如下：

1  public class ConfigurableJsonResult : JsonResult
2     {
3         public override void ExecuteResult(ControllerContext context)
4         {
5             if (context == null)
6             {
7                 throw new ArgumentNullException("context");
8             }
9             if (JsonRequestBehavior == JsonRequestBehavior.DenyGet &&
10                 String.Equals(context.HttpContext.Request.HttpMethod, "GET", StringComparison.OrdinalIgnoreCase))
11             {
12                 throw new InvalidOperationException("This request has been blocked because sensitive information could be disclosed to third party web sites when this is used in a GET request. To allow GET requests, set JsonRequestBehavior to AllowGet.");
13             }
14
15             HttpResponseBase response = context.HttpContext.Response;
16
17             if (!String.IsNullOrEmpty(ContentType))
18             {
19                 response.ContentType = ContentType;
20             }
21             else
22             {
23                 response.ContentType = "application/json";
24             }
25             if (ContentEncoding != null)
26             {
27                 response.ContentEncoding = ContentEncoding;
28             }
29             if (Data != null)
30             {
31                 JavaScriptSerializer serializer = new JavaScriptSerializer();
32
33                 ScriptingJsonSerializationSection section = ConfigurationManager.GetSection("system.web.extensions/scripting/webServices/jsonSerialization") as ScriptingJsonSerializationSection;
34
35                 if (section != null)
36                 {
37                     serializer.MaxJsonLength = section.MaxJsonLength;
38                     serializer.RecursionLimit = section.RecursionLimit;
39                 }
40
41                 response.Write(serializer.Serialize(Data));
42             }
43         }
44     }

关键在红色标记的代码，读取配置的值。JavaScriptSerializer还有其他属性可配置，没有列出与实现，暂时够用。

这样在返回长字符内容的json结果时，直接替换原JsonResult即可，同时也兼顾了可配置的灵活性。

本文链接

“无法从http://XXX/XXX.svc?wsdl获取元数据”错误的解决方法

2012-01-06T01:32:00Z

昨天在用IIS部署一个WCF服务时，碰到了如下错误：

理解了文档内容，但无法进行处理。
- WSDL 文档包含无法解析的链接。
- 下载“http://admin-pc/IISHostService/Service1.svc?xsd=xsd0”时出错。
- 基础连接已经关闭: 接收时发生错误。
- 无法从传输连接中读取数据: 远程主机强迫关闭了一个现有的连接。。
- 远程主机强迫关闭了一个现有的连接。
元数据包含无法解析的引用:“http://admin-pc/IISHostService/Service1.svc?wsdl”。
元数据包含无法解析的引用:“http://admin-pc/IISHostService/Service1.svc?wsdl”。
如果该服务已在当前解决方案中定义，请尝试生成该解决方案，然后再次添加服务引用。

该错误是在使用svcutil生成client代码时报的错误，服务是部署在IIS7上，部署的过程都是完全教科书式的进行。服务也正常启动了，显示如下内容

已创建服务。

若要测试此服务，需要创建一个客户端，并将其用于调用该服务。可以使用下列语法，从命令行中使用 svcutil.exe 工具来进行此操作:

svcutil.exe http://leo-pc/IISHostService/Service1.svc?wsdl

按照提示直接用svcutil.exe http://admin-pc/IISHostService/Service1.svc?wsdl命令去生成代码，就出现了开头说的那个错误。而如果用visual studio的webdevserver启动，则一切正常。

经过一轮谷百之后，发现网上有很多类似的情况，有的说是因为用了wsHttpBinding协议引起的，或者是元数据没有正确公开，但都不是他们说的情况。后来找到了一篇文章，说的是添加WCF引用的一个陷阱。里面提到的情形跟我遇到的一致，原来问题出在权限，难怪用webdevserver可以很正常的运行。原来在下载http://admin-pc/IISHostService/Service1.svc?xsd=xsd0时的权限不足，在浏览器直接访问这个url会提示找不到页面。原因就是IIS进程的用户没有访问Windows\Temp目录的权限。找到Temp目录，然后找到IIS_USER用户，授权即可。

具体可参考：http://merill.net/2008/04/wcf-add-service-reference-gotcha-with-windows-server/

本文链接

处理WCF异常的方式

2011-12-31T13:41:00Z

任何程序都离不开对异常的处理，良好的异常处理方式可加快寻找出异常的根源，同时也需要避免暴露敏感信息到异常中。WCF这种典型的服务端和客户端交互的程序，服务端的异常更需要适当的处理。下面以一个简单的服务为例，说明WCF中处理异常的方式。

WCF服务定义如下，很明显方法Divide在divisor为0的时候将会抛出异常

public class CalculateService : ICalculateService
    {
        public int Divide(int dividend, int divisor)
        {
            return dividend / divisor;
        }

        public int Add(int a, int b)
        {
            return a + b;
        }
    }

客户端调用如下：

using (var client = new CalculateServiceClient())
            {
                try
                {
                    Console.WriteLine(client.Divide(20, 0));
                }
                catch (FaultException ex)
                {
                    Console.WriteLine(ex.Reason);
                }

              }

首先需要知道的是，WCF的异常信息默认是以FaultException的形式返回到客户端，FaultException的关键属性Reason是对客户端反馈的最重要信息之一。以上客户端代码调用之后，默认的FaultException返回的Message信息如下：

由于内部错误，服务器无法处理该请求。有关该错误的详细信息，请打开服务器上的 IncludeExceptionDetailInFaults (从 ServiceBehaviorAttribute 或从 <serviceDebug> 配置行为)以便将异常信息发送回客户端，或在打开每个 Microsoft .NET Framework 3.0 SDK 文档的跟踪的同时检查服务器跟踪日志。

根据异常的提示，意思说如果要在客户端看到详细的Exception信息，那么请将ServiceBehavior对应的IncludeExceptionDetailInFaults属性设置为True，通常在配置中表现为如下设置：

1 <serviceBehaviors>
2         <behavior>
3           <serviceMetadata httpGetEnabled="True" httpGetUrl="http://localhost:8733/CalculateService/"/>
4           <serviceDebug includeExceptionDetailInFaults="True" />
5         </behavior>
6       </serviceBehaviors>

通过以上设置之后，客户端输出的内容为“尝试除以零”，这个提示信息跟原始的异常信息是一致，即返回的FaultException中的Reason包含原始异常的Message的值，但是这样处理之后服务端所报出的异常信息直接传到了客户端，比如一些保密信息也可能输出到了客户端，因此对于异常信息必须进行一个封装。最直接的形式莫过于在服务端就把异常给捕获了，并重新throw一个FaultException

服务端的代码改进如下，经过以下改进，那么客户端得到的信息仅仅是"操作失败"，同时服务端也记录了异常信息(这时IncludeExceptionDetailInFaults是设置为False的)。

1 try
2             {
3                 return dividend / divisor;
4             }
5             catch (Exception ex)
6             {
7                 Console.WriteLine(ex.Message);
8                 throw new FaultException("操作失败");
9             }

当然这是FaultException的默认用法，FaultException还支持强类型的异常错误信息，返回更加丰富和精确的错误提示。假设定义如下通用的一个FaultContract类型，将出错时的用户名和线程名字记录到异常信息中，因为异常信息也是通过SOAP格式传输的，因此跟定义其他DataContract的方式一样。

1     [DataContract]
2     public class CommonFaultContract
3     {
4         [DataMember]
5         public string UserName { get; set; }
6         [DataMember]
7         public string  ThreadName { get; set; }
8     }

那么服务方法的接口需要增加如下标记，如果不这样标记，那么客户端得到的异常类型依然是FaultException，而不是强类型的异常信息。

[FaultContract(typeof(CommonFaultContract))]
int Divide(int dividend, int divisor)

实现方法中抛出异常的部分代码改成如下：

1 catch (Exception ex)
2             {
3                 Console.WriteLine(ex.Message);
4                 throw new FaultException<CommonFaultContract>(new CommonFaultContract
5                 {
6                     UserName = Environment.UserName,
7                     ThreadName = System.Threading.Thread.CurrentThread.Name
8                 }, "操作失败");
9             }

这时候重新生成客户端的代理类，然后更新客户端的代码如下，红色部分即获取强类型的异常错误信息。

1 try
2                 {
3                     Console.WriteLine(client.Divide(20, 0));
4                 }
5                 catch (FaultException<CommonFaultContract> ex)
6                 {
7                     Console.WriteLine(ex.Detail.ThreadName);
8                     Console.WriteLine(ex.Detail.UserName);
9                     Console.WriteLine(ex.Reason);
10                 }

当然在具体应用中还需要根据需求，返回不同的信息，构建不同的FaultContract。

以上服务端捕获的异常方法，适用于方法比较少的情况，如果有十多个方法，一个个去写try catch然后做标记等，那么工作量会很大，而且代码也不利于重用。尝试寻找像MVC Controller那样的统一处理Exception的方式，将异常处理都放在基类中，那么只要继承与这个基类的方法都不需要去写try catch去捕获异常。但WCF中似乎没有这样的机制，放弃了这种做法。

最近在研究Enterprise Lib中对WCF的支持时，发现Exception Block中还特地有针对WCF程序异常处理的解决方案，而且满足以上说道的需求，即可记录异常，又可对异常信息进行封装。更重要的时，自动处理运行时的异常信息，不需要挨个方法的去写Try catch。秉承企业库的优秀传统，大部分工作还是通过配置就可以完成了，非常好的解决方案。下面介绍具体的使用步骤。

步骤一：

引用以下dll

Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.dll

Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.WCF.dll

Microsoft.Practices.EnterpriseLibrary.Common.dll

Microsoft.Practices.ObjectBuilder2.dll

步骤2：

在具体的实现类中，增加如下属性标记，其中WcfException为企业库中Exception Block中的一个异常处理策略，具体如何配置异常处理策略，请参考企业库的帮助文档。

[ExceptionShielding("WcfException")]
public class CalculateService : ICalculateService

那么只要增加了[ExceptionShielding("WcfException")]这个属性标记之后，所有运行时的异常都将交给策略名为WcfException的异常处理block来处理，在这里就可以执行一些异常记录以及异常封装的操作。

步骤3：

将异常信息封装为FaultException，这个动作也是通过配置来完成。在Exception节点中添加一个Fault Contract Exception Handler。

Fault Contract Exception Handler需要设置以下两个属性值

exceptionMessage：所有异常封装后的错误信息

faultContractType：即返回异常的faltContract类型，这个类型必须指定一个，哪怕方法中没有用到也要，如果方法中有用到，那么客户端那边就能得到强类型FaultException,否则就是普通的FaultException。这里指定为之前定义的CommonFaultContract。

对于faultContract类型的值，还可以通过PropertyMappings来自定义需要从原始异常信息中映射到faultContract的属性中，这个属性可选。

经过以上步骤配置之后，服务端的程序就具备了自动处理异常的功能。客户端还是跟往常那样调用，不过具体是用FaultException捕获异常还是FaultException<T>去捕获异常，还得根据定义方法中是否标记了FaultContract。之后若定义了其他服务接口，同样也仅仅需要在实现类上加上[ExceptionShielding("WcfException")]标记即可。

(图片后续补上)

本文链接

WCF中校验参数的实现方式（二）

2011-12-29T14:30:00Z

上接方法一

实现的第二种方法是利用企业库提供的针对WCF程序的validation block，如果之前有用过企业库的validation模块，那么在WCF中用起来就非常简单，在WCF中要做的大部分都是配置工作。

步骤一，引用相关的dll

Microsoft.Practices.EnterpriseLibrary.Common.dll

Microsoft.Practices.EnterpriseLibrary.Validation.dll

Microsoft.Practices.EnterpriseLibrary.Validation.Integration.WCF.dll

步骤二，在指定的接口中设置一个ValidationBehavior属性标记，该标记的目的是表明方法参数中包含需要验证逻辑。当然ValitionBehavior也可以通过配置文件形式注入，具体可参考上一篇博客内容。

1     [ServiceContract]
2     [ValidationBehavior]
3     public interface ITradeService

步骤三，在需要验证的参数上标记验证属性，以及给方法标记FaultContract。如果有多个参数，以此给指定参数加标记即可。对于FaultContract中必须指定，这样才能将验证信息返回。

1 [FaultContract(typeof(ValidationFault))]
2         string TradeSomething(
3             [StringLengthValidator(10, MessageTemplate = "ths length of qutoeName must less than {0}")]
4             string quoteName);

到此，服务单的配置就完成了。

接下来说一下客户端的如何获取错误信息。

类似其他服务，通过svcutil生成得到一个客户端类，然后如果按往常那样处理FaultException，将得不到正确的错误提示。如下代码得到的信息是“此错误的创建者没有指定原因”。

using (var client = new TradeServiceClient())
            {
                try
                {
                    Console.WriteLine(client.TradeSomething("ztejlkfjdslakfjdlskag"));
                }
                catch (Exception ex)
                {
                    Console.WriteLine(ex.Message);
                }
            }

对于企业库返回的FaultException的错误信息，需要特殊处理，对catch部分的代码做如下修改即可

using (var client = new TradeServiceClient())
            {
                try
                {
                    Console.WriteLine(client.TradeSomething("ztejlkfjdslakfjdlskag"));
                }
                catch (System.ServiceModel.FaultException<ValidationFault> ex)
                {
                    foreach (var item in ex.Detail.Details)
                    {
                        Console.WriteLine(item.Message);
                    }
                }
            }

这里需要强调的是，ValidationFault的类型必须跟服务用的一致，要么使用svcutil中自动生成的类型，或者直接引用企业库的dll。当引用企业库的dll之后，就不能使用svcutil生成的ValidationFault类型，否则无法正确接收错误提示。

本文链接

WCF中使用自定义behavior提示错误的解决方法

2011-12-29T10:38:00Z

WCF中支持自定义behavior，可通过配置的方式给endpoint或者service设置behavior。配置方法就是在system.serviceModel/extensions/behaviorExtensions节点下注册自定义的behavior，之后就可以在behaviors节点中使用。注册的配置如下

1 <extensions>
2           <behaviorExtensions>
3               <add name="validation"
4                type="Microsoft.Practices.EnterpriseLibrary.Validation.Integration.WCF.ValidationElement,
5                  Microsoft.Practices.EnterpriseLibrary.Validation.Integration.WCF,
6                  Version=4.1.0.0, Culture=neutral,
7                  PublicKeyToken=31bf3856ad364e35" />
8           </behaviorExtensions>
9       </extensions>

这里用的是企业库中用于支持WCF验证的behavior扩展。

按照enterpise library 4.1版本中的帮助文档描述是这样配置的，但是运行时却出现以下错误：

参数名: element (E:\aspnet\WcfService\TestParameterValidate\bin\Debug\TestParameterValidate.dll.config line 34) ---> System.ArgumentException: 无法将扩展元素“validation”添加到此元素中。请验证该扩展是否已在 system.serviceModel/extensions/behaviorExtensions 中的扩展集合中注册。

出现这种错误的只可能是拼写错误了，但那段配置可是从企业库的帮助文档中拷贝的，难道WCF不认企业库的dll，那可都是一家的产品。回想起之前写过一个自定义的behavior，也有这个问题，那么确定不是企业库的问题，问题还是在于WCF的配置。

经过搜索，在园子里的一篇文章提到了这个问题(http://www.cnblogs.com/hxw/archive/2009/09/17/1331641.html),说这是WCF的bug，配置中对于type的字符串必须严格按照规范来写，而且不能有换行等。照着这个思路，把type工工整整地写了一遍，还是报同样的错误，真让人崩溃。

这时想到了用WCF的配置工具，这个工具是.NET提供的，专门用于配置config中的WCF配置内容。调出的方法是对着配置文件，点击右键，然后选择"编辑WCF配置"。打开之后，所有内容都在掌控之中了。

配置extensions如下步骤：

第一步选择行为元素扩展：

第二步点击右下方的"新建"按钮，在弹出的界面中选择自定义的类型

点击确定之后，保存即可。

经过配置之后，工具生成的配置代码如下，咋一看没什么区别，但重要的是，能运行起来而且不会报错。

1 <behaviorExtensions>
2 <add name="validation" type="Microsoft.Practices.EnterpriseLibrary.Validation.Integration.WCF.ValidationElement, Microsoft.Practices.EnterpriseLibrary.Validation.Integration.WCF, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
3 </behaviorExtensions>

本文链接

WCF中校验参数的实现方式（一）

2011-12-28T13:55:00Z

在用WCF写服务程序时，有时候需要做一些参数的校验，当然这些参数校验可放到调用端处理，但服务为了保险起见也需要有对参数的校验处理。如果服务不多，那么可直接在服务的方法中去校验，然后直接扔个异常或者返回错误结果。但这种针对单个方法写得校验不可重用，希望能有一种类似model校验的方式，加个标记或者属性配置一下就可以。毕竟校验这块不是WCF的重点内容，将校验代码放入到服务实现中也不太合理。WCF提供了一些扩展的地方，可以在运行时去校验参数是否合法，通过定义一些behavior，然后加在需要校验的方法上就可实现对方法参数的校验。

下面说说WCF中两种校验输入参数的实现方法。

方法一：

自定义校验方法的behavior，然后将这个behavior作为属性标记在接口的方法上。具体涉及到的接口有IParameterInspector，IOperationBehavior。

IParameterInspector

很明显就是用于对参数的检测，具体对参数的检测都是在这个接口的BeforeCall方法中实现。下面定义的是一个对参数长度的校验实现，当校验失败后通过返回异常的方式传递错误信息。其中ParameterIndex是参数的索引，MaxLength只参数的最大长度。

1 public class LengthParameterInspector : IParameterInspector
2     {
3         public int ParameterIndex { get; private set; }
4
5         public int MaxLength { get; private set; }
6
7         public LengthParameterInspector(int parameterIndex, int maxLength)
8         {
9             this.ParameterIndex = parameterIndex;
10             this.MaxLength = maxLength;
11         }
12
13         public void AfterCall(string operationName, object[] outputs, object returnValue, object correlationState)
14         {
15             //throw new NotImplementedException();
16         }
17
18         public object BeforeCall(string operationName, object[] inputs)
19         {
20             if (inputs.Length < ParameterIndex)
21             {
22                 return null;
23             }
24
25             string input = inputs[ParameterIndex] as string;
26
27             if (input != null)
28             {
29                 if (input.Length > this.MaxLength)
30                 {
31                     throw new FaultException(string.Format("the length of parameter {0} must less than {1}", ParameterIndex.ToString(), MaxLength.ToString()));
32                 }
33             }
34
35             return null;
36         }
37     }

IOperationBehavior

就是用于方法的行为接口，通过ApplyDispatchBehavior方法加入实现了IParameterInspector的实例（红色部分代码）。实际上是一个Attribute，那么就可以直接用在服务的方法中。

1 [AttributeUsage(AttributeTargets.Method, AllowMultiple = false)]
2     public class LengthValidateBehavior: Attribute, IOperationBehavior
3     {
4         private int parameterIndex;
5         private int maxLength;
6
7         public LengthValidateBehavior(int parameterIndex, int maxLength)
8         {
9             this.parameterIndex = parameterIndex;
10             this.maxLength = maxLength;
11         }
12
13         public void AddBindingParameters(OperationDescription operationDescription, System.ServiceModel.Channels.BindingParameterCollection bindingParameters)
14         {
15             //throw new NotImplementedException();
16         }
17
18         public void ApplyClientBehavior(OperationDescription operationDescription, System.ServiceModel.Dispatcher.ClientOperation clientOperation)
19         {
20             //throw new NotImplementedException();
21         }
22
23         public void ApplyDispatchBehavior(OperationDescription operationDescription, System.ServiceModel.Dispatcher.DispatchOperation dispatchOperation)
24         {
25             dispatchOperation.ParameterInspectors.Add(new LengthParameterInspector(parameterIndex, maxLength));
26             //throw new NotImplementedException();
27         }
28
29         public void Validate(OperationDescription operationDescription)
30         {
31             //throw new NotImplementedException();
32         }
33     }

具体在方法中的使用如下，即校验第一个参数的长度，最大长度不能超过10个字。

1     [ServiceContract]
2     public interface ITradeService
3     {
4         [OperationContract]
5         [LengthValidateBehavior(0, 10)]
6         string TradeSomething(string quoteName);
7     }

完成以上步骤之后，就可实现简单的参数校验。但这种方式对于多参数时，不好使，因为WCF中不支持对同一个方法定义多个相同类型的Behavior,即使Attribute中指定了AllowMultiple=true也无效。

下面介绍第二种方法，借助企业库的校验模块实现对参数校验。

方法二：

后续更新

本文链接

WCF使用时碰到个莫名其妙的异常

2011-12-20T01:48:00Z

昨天在调试WCF服务时，碰到个异常，异常信息都让人看不懂。之前也没碰到过，折腾了一会才弄明白原因。

像往常一样创建一个WCF库，就是可直接调试的那种WCF服务。然后加入了一个服务，该服务还用到了复杂自定义类型作为DataContract，并像往常一样启动调试，居然蹦出了一个错误提示框，里面有一些错误信息，命名空间“TestNamespace.System”中不存在类型或命名空间名称“Runtime”(是缺少程序集引用吗?)，如下图：

其中TestNamespace.System命名空间下是复杂类型所在的命名空间。出现这样的错误，一时让人毫无头绪。为什么回去自定义类型中去寻找Runtime和CodeDom这些东西呢？看起来像要实现什么动态处理的功能，或者动态代码生成。于是问题定位在自己定义的复杂类型中，去掉相关的引用后，改成系统的内置简单类型之后，就不出异常了。但总不能都用简单类型吧，之前也有这样的用法，都是OK的。
　　最后求助万能的古戈，发现问题居然是出在命名空间上。原来是命名空间中包含了System关键字，然后系统在运行时会把用户自定义的System命名空间当做了系统内置的System命名空间，然后很自然的去寻找相关的系统类型，结果报出以上错误。更改命名空间的名字之后，问题解决。具体可参见http://stackoverflow.com/questions/3037098/compile-error-the-type-or-namespace-name-runtime-does-not-exist-in-the-names中二楼的回复内容。

估计.NET中就是这么规定的，其他方面应该也会有这方面的限制，避免有这些关键字就OK了。不过提示信息确实不够明确，让人看不懂。

本文链接

Request.QueryString与一般NameValueCollection的区别

2011-12-08T15:04:00Z

最近在做一个搜索程序的优化改进，将搜索结果按照查询的参数不同进行缓存。缓存的Key很自然的就想到了用查询字符串，而获取查询字符串的最简单方式是通过Request.QueryString.ToString()方法。查看了QueryString的定义类型是NameValueCollection，就误以为这是NameValueCollection的重写了ToString()的方法，于是放心地将代码转移到了业务逻辑层。因为还要重构查询参数，因此重新构建了一个NameValueCollection，并想当然地用ToString()的结果作为Key。但实际运行之后发现，每次的结果都一样的，都是第一次的查询结果。经调试，发现NameValueCollection的ToString()方法并没有重新，还是返回的是“System.Collections.Specialized.NameValueCollection”。

先看看调试时的情况，发现QueryString的实际类型是System.Web.HttpValueCollection,该类型继承自NameObjectCollectionBase,跟NameValueCollection的基类是一样的。那么最有可能的就是QueryString直接继承了NameValueCollection，并且重写了ToString()的方法。

普通NameValueCollection的表现如下

根据以上判断基本为什么QueryString表面上看起来是NameValueCollection但又实际上表现出不同的ToString表现。

接下来继续了解一下System.Web.HttpValueCollection是何方神圣。该类用起来似乎很方便，也尝试在代码中使用，但提示找不到类。在MSDN中也没有明确该类的记录，可以基本判定为私有的类型或者受保护的。搜索之后发现，该类是的完整定义是System.Web.HttpValueCollection, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a，只能通过反射的方式访问或修改该类型。因此想用这个类的话，基本上是比较麻烦，不太值得。但是在一般开发者眼中，都希望查询字符串的和NameValueCollection能很顺畅的进行呼唤，通过ToString()的简单方式就能获得。目前要实现两者的转换有以下方式

从查询字符串内容转换到NameValueCollection

HttpUtility.ParseQueryString(querystring);(参考http://msdn.microsoft.com/zh-cn/library/ms150046(v=VS.90).aspx)，这种方式得到的就是正品QueryString,ToString()后为所实际的值。

从NameValueCollection转化的为查询字符串

只能遍历NameValueCollection，然后自个拼出一个查询字符串了

1             foreach (string key in c.Keys)
2              {
3                  sb.AppendFormat("{0}={1}", key, c[key]);
4              }

但实际上我们希望有更自然的方式，因为往往我们跟乐于操作可读写的NameValueCollection，而不是只读的QueryString。

老外对此也提出了意见，具体可参考

http://msmvps.com/blogs/paulomorgado/archive/2008/07/15/make-the-httpvaluecollection-class-public-and-move-it-to-system-dll.aspx

本文链接

const和readonly内部区别

2011-11-29T13:04:00Z

const和readonly关键字也是面试中经常考到的问题，通常都是用来表示一个不可变的变量成员，那么具体区别是什么？从用法上说，const只能以inline代码的形式定义，而readonly既可以以inline代码形式定义也可以通过构造方法定义。CLR中定义，readonly的变量只能在构造方法中赋值，而C#中inline代码实际上是构造方法调用的一部分，因此readonly的变量可以以inline的方式赋值。

以上是语法方面的应用，那在实际上的用法上，还是有些微妙的变化，通常不易发觉，请看下面的代码

在程序集ConstLib.dll中有一个类MyClass，定义了一个公开的静态变量MaxCount

1     public static class MyClass
2     {
3         public const int MaxCount = 20;
4     }

然后另外一个应用程序ConstTest.exe 引用constLib.dll，并在代码中作如下调用

1         static void Main(string[] args)
2         {
3             Console.WriteLine(MyClass.MaxCount);
4
5             Console.ReadLine();
6         }

毫无疑问，非常简单的代码，直接输出20。

接下来更新MyClass的MaxCount的值为30，然后重新编译ConstLib.dll，并更新到应用程序的所在目录中，注意不能编译应用程序。那么这时候的输出结果按预期那么想应该是30才对，但实际上还是20，为什么呢？

这就是const的特别之处，有多特别还是直接看生成的IL，查看ConstTestIL代码(假设这时候MaxCount的值为20)

IL_0000: nop
IL_0001: ldc.i4.s 20
IL_0003: call void [mscorlib]System.Console::WriteLine(int32)

红色代码很明显的表明了，直接加载20，没有通过任何类型的加载然后得到对应变量的，也就是说在运行时没有去加载ConstLib.dll，那么是否意味着没有ConstLib.dll也可以运行呢？答案是肯定的，删除ConstLib.dll也可以运行，是否很诡异呢？也就解释了之前的实验，为什么更新const变量的值之后没有调用新的值，因为ConstText.exe在运行的时候根本不会去加载ConstLib.dll。那么20这个值是从哪来的呢？实际上CLR对于const变量做了特殊处理，是将const的值直接嵌入在生成的IL代码中，在执行的时候不会再去请求dll加载。这也带来了一个不容易发觉的bug，因此在引用其他程序集的const变量时，需考虑到版本更新问题，要解决这个问题就是把调用的应用程序再编译一次就ok了。但实际程序部署更新时可能只更新个别文件，这时候就必须用readonly关键字来解决这个问题。

接下来看readonly的版本

1     public static class MyClass
2     {
3         public static readonly int MaxCount = 20;
4     }

调用方代码不变，接着看看ConstTest.exe生成的IL代码

IL_0001: ldsfld int32 [ConstLib]ConstLib.MyClass::MaxCount
IL_0006: call void [mscorlib]System.Console::WriteLine(int32)

很明显加载代码变了，一个很常见的ldsfld动作，请求了ConstLib.MyClass的MaxCount变量，是通过强制要求加载ConstLib来实现的。因此这时候更新MaxCount的值重新编译之后，ConstText.exe还是不编译，然后再执行就会看到新的值。而这时候如果删除ConstLib.dll那么，会出现运行时报错找不到dll之类的异常。这也充分说明了对于readonly定义的变量是在运行时加载的。

总结const和readonly的最大区别(除语法外)

const的变量时嵌入在IL代码中，编译时就加载好，不依赖外部dll（这也是为什么不能在构造方法中赋值）。const在程序集更新时容易产生版本不一致的不管。

readonly的变量是在运行时加载，需请求加载dll，每次都获取最新的值。

本文链接