我使用下面的代码行来解决这个问题。在web中编写以下代码。配置文件

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

极好的。

情况2 -同样的问题可以出现)在我的情况下，问题是由于以下一行:

<webServices>
  <protocols>
    <remove name="Documentation"/>
  </protocols>
</webServices>

它在服务器上工作得很好，因为直接调用webservice函数——但是如果你在调试环境中直接从。net运行服务，并且想要手动测试运行该函数，则会失败。

在html中，你必须将调用包含在一个带有GET的表单中

<a href="/service/servicename.asmx/FunctionName/parameter=SomeValue">label</a>

您还可以使用POST，其操作是web服务的位置，并通过输入标记输入参数。

还有SOAP和代理类。

确保您禁用了自定义错误。这可以掩盖代码中的原始问题:

改变

<customErrors defaultRedirect="~/Error" mode="On">

to

<customErrors defaultRedirect="~/Error" mode="Off">

一个需要ContextKey的WebMethod，

[WebMethod]
public string[] GetValues(string prefixText, int count, string contextKey)

当此键未设置时，得到异常。

通过分配AutoCompleteExtender的键来修复它。

ac.ContextKey = "myKey";

在我们的例子中，问题是由使用OPTIONS请求方法(而不是GET或POST)调用web服务引起的。

我们仍然不知道为什么问题突然出现了。该web服务已经在HTTP和HTTPS上运行了5年。我们是唯一使用web服务的人，而且它总是使用POST。

最近，我们决定让网站只托管web服务SSL。我们向Web添加了重写规则。配置，将任何HTTP转换为HTTPS，部署，并立即开始获取，在常规的GET和POST请求之上，OPTIONS请求。OPTIONS请求导致了本文中讨论的错误。

应用程序的其余部分工作得非常好。但是由于这个问题，我们不断收到数百个错误报告。

有几篇文章(例如这篇)讨论了如何处理OPTIONS方法。我们直接在Global.asax中处理OPTIONS请求。这使问题消失了。

    protected void Application_BeginRequest(object sender, EventArgs e)
    {
        var req = HttpContext.Current.Request;
        var resp = HttpContext.Current.Response;

        if (req.HttpMethod == "OPTIONS")
        {
            //These headers are handling the "pre-flight" OPTIONS call sent by the browser
            resp.AddHeader("Access-Control-Allow-Methods", "GET, POST");
            resp.AddHeader("Access-Control-Allow-Headers", "Origin, Content-Type, Accept, SOAPAction");
            resp.AddHeader("Access-Control-Max-Age", "1728000");
            resp.End();
        }
    }