用大串传输DataMember

Question

在IIS8.0中托管的(.NET FW4.0)中，我想将包含两个大字符串的复杂DataMember作为参数发送。这些字符串最多可达20 MB或更多MB。首先我使用了transferMode=Streamed，但是我总是得到错误：

附加信息:格式化程序在反序列化消息时抛出一个异常:试图反序列化参数http://tempuri.org/:request时出错。InnerException消息是：“反序列化QCheckerService.Parameter类型的对象时出错。读取XML数据时超过了最大字符串内容长度配额(8192)。在创建XML读取器时，可以通过更改XmlDictionaryReaderQuotas对象上的MaxStringContentLength属性来增加该配额。

我在配置文件中将readerQuotas全部设置为max。但错误与XmlDictionaryReaderQuotas有关。是否有办法避免在代码中更改后一个配额？

我现在有点搞不懂怎样才是合适的解决办法。默认的transferMode=Buffered是正确的方法吗？

或者是大字符串的传输是不可能的，我应该用另一种方式？

如果我传输小字符串，它就能工作。这里是附加的配置。

客户端app.config：

<system.serviceModel>
  <client>
    <endpoint address=http://localhost:12412/Service1.svc 
              binding="basicHttpBinding"
              bindingConfiguration="BasicHttpBinding_IQChecker"
              contract="QCheckerService.IQChecker"> 
  </client>
  <bindings>
    <basicHttpBinding>
      <binding name="BasicHttpBinding_IQChecker" 
                     maxBufferSize="2147483647" 
                     maxBufferPoolSize="2147483647" 
                     maxReceivedMessageSize="2147483647"
                     transferMode="Streamed">
        <readerQuotas maxDepth="32" 
                      maxStringContentLength="2147483647"
                      maxArrayLength="2147483647" 
                      maxBytesPerRead="2147483647" 
                      maxNameTableCharCount="2147483647" />
      </binding>
    </basicHttpBinding>
  </bindings>
</system.serviceModel>

服务web.config：

<system.serviceModel>
  <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
  <bindings>
    <basicHttpBinding>
      <binding name="Basic"
               maxReceivedMessageSize="2147483647"
               maxBufferSize="2147483647"
               maxBufferPoolSize="2147483647"
               transferMode="Streamed">
        <readerQuotas maxBytesPerRead="2147483647"
                      maxDepth="32"
                      maxStringContentLength="2147483647"
                      maxArrayLength="2147483647"
                      maxNameTableCharCount="2147483647" />
      </binding>
    </basicHttpBinding>
  </bindings>
  <behaviors>
    <serviceBehaviors>
      <behavior>
        <serviceMetadata httpGetEnabled="true"/>
      </behavior>
    </serviceBehaviors>
  </behaviors>
</system.serviceModel>

相关DataMember的服务接口

[OperationContract]
[WebInvoke(Method = "POST", UriTemplate = "MyMethod", BodyStyle = WebMessageBodyStyle.Bare)]
ReturnValue MyMethod (Parameter request);

[DataContract]
public class Parameter: IDisposable
{
    [DataMember]
    String String1;

    [DataMember]
    String String2;

    public void SetString1(String drawing)
    {
        String1 = drawing;
    }

    public String GetString1()
    {
        return String1;
    }

    public void SetString2(String configuration)
    {
        String2 = configuration;
    }

    public String GetString2()
    {
        return String2;
    }

    public void Dispose()
    {

    }

谢谢你的建议。

Answer 1

在服务的配置文件中，您已经定义了一个名为"Basic“的basicHttpBinding。但是，您没有显式定义服务的端点，因此默认情况下，框架将在服务文件的位置公开一个带有basicHttpBinding的端点。这个默认端点将对缺省值使用basicHttpBinding -换句话说，您定义的绑定根本不使用。

修复此问题的两种方法(在WCF 4.0+中)：您必须将该绑定按其名称分配给一个显式端点(该端点也在配置文件中定义)，或者将其设置为该传输协议的默认绑定。

对于选项a，可以将端点添加到服务的配置文件中：

<services>
  <service name="Your service name">
    <endpoint address="" 
              binding="basicHttpBinding"
              bindingConfiguration="Basic" 
              contract="QCheckerService.IQChecker" />
  </service>
</services>

对于选项b，可以通过在绑定定义上添加name属性来使您指定的配置为默认配置，如下所示：

<bindings>
  <basicHttpBinding>
    <binding maxReceivedMessageSize="2147483647"
             maxBufferSize="2147483647"
             maxBufferPoolSize="2147483647"
             transferMode="Streamed">
      <readerQuotas maxBytesPerRead="2147483647"
                    maxDepth="32"
                    maxStringContentLength="2147483647"
                    maxArrayLength="2147483647"
                    maxNameTableCharCount="2147483647" />
    </binding>
  </basicHttpBinding>
</bindings>

上述绑定定义将用于使用该配置文件和basicHttpBinding的所有服务。

有关默认绑定、端点和行为的详细信息，请参阅开发人员介绍Windows通信基金会4。