【问题标题】:This could be due to the service endpoint binding not using the HTTP protocol这可能是由于服务端点绑定未使用 HTTP 协议
【发布时间】:2011-08-17 18:38:14
【问题描述】:

我有一个 WCF 服务在我的本地机器上运行良好。我把它放在服务器上,我收到以下错误:

接收时发生错误 HTTP 响应 http://xx.xx.x.xx:8200/Services/WCFClient.svc。 这可能是由于服务 不使用 HTTP 的端点绑定 协议。这也可能是由于 HTTP 请求上下文被中止 服务器(可能是由于 服务关闭)。见服务器 日志以获取更多详细信息。]

我已经访问了 url 中的服务,它工作正常。我为该函数所做的只是将字符串返回到图像名称,因此传递的数据并不多。我跟踪了日志,它给了我相同的信息。这是我的客户端配置:

<binding name="basicHttpBinding_IWCFClient" closeTimeout="00:01:00"
         openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
         bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
         maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647"
         messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
         allowCookies="false">
    <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" 
                  maxArrayLength="2147483647" maxBytesPerRead="2147483647" 
                  maxNameTableCharCount="2147483647" />
    <security mode="None">
        <transport clientCredentialType="None" proxyCredentialType="None" realm="" />
        <message clientCredentialType="UserName" algorithmSuite="Default" />
    </security>
</binding>
<endpoint name="basicHttpBinding_IWCFClient" 
    address="http://localhost:4295/Services/WCFClient.svc"
    binding="basicHttpBinding" 
    bindingConfiguration="basicHttpBinding_IWCFClient" 
    behaviorConfiguration="WCFGraphicManagementTool.Services.ClientBehavior"
    contract="WCFClient.IWCFClient" />

这是我的服务器配置:

<service behaviorConfiguration="WCFGraphicManagementTool.Services.WCFClientBehavior"
    name="WCFGraphicManagementTool.Services.WCFClient">
   <endpoint name="basicHttpBinding_IWCFClient"
       address="" 
       binding="basicHttpBinding" 
       contract="WCFGraphicManagementTool.Contracts.IWCFClient" />
   <endpoint 
       address="mex" 
       binding="mexHttpBinding" 
       contract="IMetadataExchange" />
</service>
<behavior name="WCFGraphicManagementTool.Services.WCFClientBehavior">
   <dataContractSerializer maxItemsInObjectGraph="2147483647" />
   <serviceThrottling maxConcurrentCalls="120" maxConcurrentSessions="120"
                      maxConcurrentInstances="120" />
   <serviceMetadata httpGetEnabled="true" />
   <serviceDebug includeExceptionDetailInFaults="true" />
</behavior>

因为它在我的本地机器上工作,所以它会是服务器上的设置吗?

【问题讨论】:

标签: wcf exception-handling wcf-binding net.tcp wcf-endpoint


【解决方案1】:

我认为存在序列化问题,您只需在&lt;configuration&gt; 部分的服务配置中添加以下代码即可找到确切的错误。

配置更新后"App_tracelog.svclog" 文件将创建,您的服务所在的位置只需要打开.svclog 文件并在左侧面板上找到红色线,这是错误并查看其描述以获取更多信息。

我希望这将有助于找到您的错误。

<configuration>
...
...

<system.diagnostics>
    <sources>
      <source name="System.ServiceModel.MessageLogging" switchValue="Warning, ActivityTracing">
        <listeners>
          <add name="ServiceModelTraceListener" />
        </listeners>
      </source>
      <source name="System.ServiceModel" switchValue="Verbose,ActivityTracing">
        <listeners>
          <add name="ServiceModelTraceListener" />
        </listeners>
      </source>
      <source name="System.Runtime.Serialization" switchValue="Verbose,ActivityTracing">
        <listeners>
          <add name="ServiceModelTraceListener" />
        </listeners>
      </source>
    </sources>
    <sharedListeners>
      <add initializeData="App_tracelog.svclog" type="System.Diagnostics.XmlWriterTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ServiceModelTraceListener" traceOutputOptions="Timestamp" />
    </sharedListeners>
  </system.diagnostics>

  </configuration>

更新: 如果您无法找到更新的"App_tracelog.svclog" 文件,请查找"&lt;some GUID&gt;App_tracelog.svclog",例如"a39e3026-5dd8-4d39-842a-04d486615eedApp_tracelog.svclog"

【讨论】:

  • 这实际上挽救了我的一天。这确实是一个序列化问题,我在跟踪中丢失了System.Runtime.Serialization 源。
  • 很好......不知道这个:)
  • 史诗!将在任何异常中都不可用的错误写入 App_tracelog.svclog 文件
  • 太棒了!谢谢
  • 确保将&lt;system.diagnostics&gt; 部分粘贴到文件的结尾,就在&lt;/configuration&gt; 上方。如果将其粘贴到顶部,则在运行应用时可能会出现内容类型错误。
【解决方案2】:

我遇到了这个问题“这可能是由于服务端点绑定没有使用 HTTP 协议”并且 WCF 服务将关闭(在开发机器中)

我发现:在我的情况下,问题是因为枚举,

我用这个解决了

    [DataContract]
    [Flags]
    public enum Fruits
    {
        [EnumMember]
        APPLE = 1,
        [EnumMember]
        BALL = 2,
        [EnumMember]
        ORANGE = 3 

    }

我必须用 DataContract、Flags 和所有每个枚举成员都用 EnumMember 属性装饰我的枚举。

我看了这个msdn Reference后解决了这个问题:

【讨论】:

  • 谢谢。这正是我必须做的。
  • 谢谢,你为我节省了大量时间
  • 非常感谢.. 节省了我很多时间
  • 与此相关 - 如果您在合同上的枚举类型不是 DataMember 的类型,那么您将收到此错误。我只是添加了一个 DataMember 属性,并为其赋予了非 DataContract 枚举类型。
  • 枚举不也是需要从索引0开始的吗?这在过去对我来说肯定是一个问题。所以在上面的例子中 APPLE = 0 而不是 1。
【解决方案3】:

我遇到了同样的错误,问题是序列化。我设法使用服务跟踪查看器http://msdn.microsoft.com/en-us/library/ms732023.aspx 找到了真正的问题并轻松解决了它。 也许这会对某人有所帮助。

【讨论】:

    【解决方案4】:

    在我的例子中,产生错误是因为我的一个复杂类型有一个没有 set 方法的属性。

    序列化程序因此引发了异常。添加了内部设置方法,一切正常。

    找出发生这种情况的最佳方法(在我看来)是启用跟踪日志记录。

    我通过将以下部分添加到我的web.config 来实现这一点:

    <system.diagnostics>
      <sources>
        <source name="System.ServiceModel.MessageLogging" switchValue="Warning,ActivityTracing">
          <listeners>
            <add name="traceListener"
                  type="System.Diagnostics.XmlWriterTraceListener"
                  initializeData= "c:\log\Traces.svclog" />
            <add type="System.Diagnostics.DefaultTraceListener" name="Default" />
          </listeners>
        </source>
        <source propagateActivity="true" name="System.ServiceModel" switchValue="Verbose,ActivityTracing">
          <listeners>
            <add name="traceListener"
                  type="System.Diagnostics.XmlWriterTraceListener"
                  initializeData= "c:\log\Traces.svclog" />
            <add type="System.Diagnostics.DefaultTraceListener" name="Default" />
          </listeners>
        </source>
      </sources>
      <trace autoflush="true" />
    </system.diagnostics>
    

    设置完成后,我运行我的客户端,出现异常并检查了“Traces.svclog”文件。从那里,我只需要找到异常。

    【讨论】:

    • autoflush=true 是关键
    【解决方案5】:

    使用 DataContract 的解决方案,枚举标志看起来有点难看。在我的情况下,通过在枚举中添加类似“NotSet = 0”的内容来解决问题:

    public enum Fruits
    {
      UNKNOWN = 0,
      APPLE = 1,
      BALL = 2,
      ORANGE = 3 
    }
    

    【讨论】:

    • 啊,是的,抱歉,刚刚评论了一个进一步的答案。我也看到过这种行为。
    • 解释:我遇到了同样的问题。 @Rikin 的回答让我想到:“InnerException 消息是 'Enum value '0' is invalid for type...”来自 [social.msdn.microsoft.com/Forums/vstudio/en-US/… 我得到了 jem:“这里的问题是你没有初始化 ..响应,它采用默认(和无效)值'0'......所以它不能被序列化“。
    【解决方案6】:

    我遇到了同样的问题,并用下面的代码解决了。 (如果有任何 TLS 连接问题)

    System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;
    

    请在打开客户频道前粘贴此行。

    【讨论】:

      【解决方案7】:

      我看到这个错误是由对象图中的循环引用引起的。包含来自子对象的指向父对象的指针将导致序列化程序循环,并最终超过最大消息大小。

      【讨论】:

        【解决方案8】:

        我为此苦苦挣扎了几天,并尝试了这篇文章和许多其他人的所有答案,并分享了我的解决方案,因为症状相同但问题不同。

        问题是应用程序池配置了内存限制,它只是在可变时间段后被回收。

        希望这对其他人有所帮助!
        问候,

        【讨论】:

          【解决方案9】:

          我发现了问题所在。它最终成为我的配置文件的路径是错误的。 WCF 的错误有时很有帮助。

          【讨论】:

            【解决方案10】:

            要解决这个问题,我们必须changed the AppPool Identity to an administrator account

            【讨论】:

            • 这对我很有用。我没有完全按照 Sarjan 的建议去做,只是将应用程序文件夹(在 wwwroot... 下)的读/写权限授予了我正在使用的应用程序池标识。
            【解决方案11】:

            此错误可能是由于合同不匹配造成的。考虑下面的三层应用程序......

            界面层
            |
            工艺层
            |
            数据访问层
            -> 进程和 UI 层之间的合同具有相同的枚举但缺少 (Onhold = 3)。枚举:开始 = 1,停止 = 2。 -> Data Access And Process 层之间的 Contract 有 enum Enum: Start = 1,Stop = 2,Onhold = 3。

            在这种情况下,我们将在流程层响应中得到相同的错误。

            多层应用中的其他合约不匹配也会出现同样的错误。

            【讨论】:

            【解决方案12】:

            我遇到了这个问题,因为我将 WCF 服务配置为返回 System.Data.DataTable。

            它在我的测试 HTML 页面中运行良好,但是当我将它放入我的 Windows 窗体应用程序时崩溃了。

            我必须进去将服务的操作合同签名从 DataTable 更改为 DataSet 并相应地返回数据。

            如果您遇到此问题,您可能需要向您的服务添加额外的操作合同,这样您就不必担心破坏依赖现有服务的代码。

            【讨论】:

              【解决方案13】:

              这可能有很多原因;以下是其中的几个:

              1. 如果您使用复杂的数据协定对象(即具有更多子自定义对象的自定义对象),请确保所有自定义对象都使用 DataContract 和 DataMember 属性进行修饰
              2. 如果您的数据协定对象使用继承,请确保所有基类都具有 DataContract 和 DataMember 属性。此外,您需要让基类指定派生类 [KnownType(typeof(BaseClassType))] 属性(check out more info here on this)。

              3. 确保所有数据协定对象属性都具有 get 和 set 属性。

              【讨论】:

                【解决方案14】:

                我的问题是客户端和服务器之间传递的项目太多。我不得不在双方的行为中更改此设置。

                <dataContractSerializer maxItemsInObjectGraph="2147483646"/>
                

                【讨论】:

                • 我使用了相同的解决方案。但是我必须按照@100r 的建议使用 Service Trace Viewer 来查看错误。
                【解决方案15】:

                这可能与您的具体问题无关,但您提到的错误消息有很多原因,其中之一是使用了 [OperationContract] 的返回类型,该类型是抽象的、接口的或 WCF 客户端不知道的代码。

                查看下面的帖子(和解决方案)

                https://stackoverflow.com/a/5310951/74138

                【讨论】:

                  【解决方案16】:

                  我认为解决此问题的最佳方法是遵循错误建议,从而查找服务器日志。 为了启用我添加的日志

                   <system.diagnostics>
                      <sources>
                        <source name="System.ServiceModel" switchValue="Information, ActivityTracing" propagateActivity="true">
                          <listeners>
                            <add name="traceListener" type="System.Diagnostics.XmlWriterTraceListener" initializeData="c:\logs\TracesServ_ce.svclog" />
                          </listeners>
                        </source>
                      </sources>
                    </system.diagnostics>
                  

                  然后你去 c:\logs\TracesServ_ce.svclog 用微软打开它 服务跟踪查看器。看看问题到底出在哪里。

                  【讨论】:

                    【解决方案17】:

                    有关此问题的更多信息,另请参阅: An existing connection was forcibly closed by the remote host - WCF

                    我的问题最终是我的数据传输对象太复杂了。从public long Id { get; set; } 之类的简单属性开始,一旦您开始工作,就可以根据需要开始添加其他内容。

                    【讨论】:

                      【解决方案18】:

                      我的问题是,我的服务的返回类型是字符串。 但我返回了 xml 类型的字符串:

                      <reponse><state>1</state><message>Operation was successfull</message</response>
                      

                      所以抛出了错误。

                      【讨论】:

                        【解决方案19】:

                        就我而言

                        我的服务对download Files具有功能

                        这个错误只在尝试下载Big Files时出现

                        所以我发现this answermaxRequestLength 增加到web.config 中所需的值

                        我知道这很奇怪,但问题解决了

                        如果您不进行任何上传或下载操作,则此答案可能对您没有帮助

                        【讨论】:

                          【解决方案20】:

                          对我来说这个错误的解决方案很奇怪。这是EndpointAddress的端口地址问题。在 Visual Studio 中,文件的端口地址(例如 Service1.svc)和 wcf 项目的端口地址必须与您在 EndpointAddress 中提供的端口地址相同。让我详细描述一下这个解决方案。

                          检查端口地址有两个步骤。

                          1. 在您的 WCF 项目中,右键单击您的服务文件(例如 Service1.svc)-> 现在在您的浏览器中选择 在浏览器中查看,您的 URL 类似于 http://localhost:61122/Service1.svc 现在记下您的端口地址为 61122

                          2. 右键单击您的 wcf 项目 -> 选择 属性 -> 转到 Web 选项卡 -> 现在在 服务器部分 -> 选择 Use Visual Studio Development Server -> 选择 Specific Port 并给出我们之前从 Service1.svc 服务中找到的端口地址。那是(61122)

                          之前我有不同的端口地址。在正确指定我已提供给 EndpointAddress 的端口地址后,我的问题就解决了。

                          我希望这可以解决您的问题。

                          【讨论】:

                            【解决方案21】:

                            也有这个问题,是因为忘记用 DataContract 和 DataMember 属性装饰我的模型

                            【讨论】:

                              【解决方案22】:

                              如果你有一个数据库(在 Visual Studio 中工作),请确保表中没有外键,我有外键,它给了我这个错误,当我删除它们时它运行顺利

                              【讨论】:

                                【解决方案23】:

                                我意识到这个问题似乎有很多“解决方案”。我在调用 wsdl 的 VB.NET 应用程序中遇到了同样的错误消息。我发布应用程序的框架是 3.5,IT 最近在我的应用程序服务器上禁用了 TLS 1.0 和 1.1,该应用程序作为计划任务运行。

                                将应用程序框架定位到 4.5.2 为我解决了这个问题。

                                【讨论】:

                                  猜你喜欢
                                  • 2013-10-08
                                  • 2021-09-29
                                  • 1970-01-01
                                  • 1970-01-01
                                  • 2011-07-15
                                  • 1970-01-01
                                  • 2021-03-22
                                  • 2011-06-15
                                  • 1970-01-01
                                  相关资源
                                  最近更新 更多