locked
maxJsonLength attribute in web.config is ignored RRS feed

  • Frage

  • We have a custom web part on a SharePoint site that returns "Error during serialization or deserialization using the JSON JavaScriptSerializer. The length of the string exceeds the value set on the maxJsonLength property." I have modified the web.config file for that site by adding the maxJsonLength attribute and setting it to its max value, but it doesn't seem to do anything. Any help is greatly appreciated.
    Freitag, 23. Juli 2010 22:42

Antworten

  • Thanks for the feedback. I've tried various values, i.e. 50000000 and 2147483647. Just to test, I tried setting it as low as 500 to see if a standard working operation would error out, but that did not. That was what lead me to believe the value in my web.config file was just being ignored. Also, I can confirm that we do explicitly create an instance of the JavaScriptSerializer class.

    I believe the behavior your are describing is "just the way it is."  Reviewing this docs page:

    http://msdn.microsoft.com/en-us/library/system.web.configuration.scriptingjsonserializationsection.maxjsonlength.aspx

     

    I see in the remarks section that "The value of the MaxJsonLength property applies only to the internal JavaScriptSerializer instance that is used by the asynchronous communication layer to invoke Web services methods."

    If I'm reading that correctly, that means that only web methods (not MVC action methods) will observe the value set by the maxJsonLength property.  If that's the case, I suspect this is an oversight on behalf of the ASP.NET MVC team--I can't imagine why wouldn't want the Controller.Json(objectToSerialize) method to also use the maxJsonLength method.

    As a workaround, you can do the following:

                JavaScriptSerializer serializer = new JavaScriptSerializer();

                serializer.MaxJsonLength = Int32.MaxValue; // Whatever max length you want here

                var resultData = new { Value = "3", Text = "MD" }; // Whatever value you are serializing

                ContentResult result = new ContentResult();

                result.Content = serializer.Serialize(resultData);

                result.ContentType = "application/json";

                return r;

     

    Then you have the option of creating your own helper methods and/or result types to wrap that up into a convenient package.  For instance, you could create a "LargeJsonResult" class that inherits from ContentResult, and takes the result object as a constructor parameter.  Then, in your action methods, you can simply do: "return LargeJsonResult(objectToSerializeToJson);"


    -jb
    • Als Antwort markiert AHuang3545 Freitag, 13. August 2010 22:37
    Donnerstag, 12. August 2010 13:35

Alle Antworten

  • Hi,

    How much is the max value you set?

    It seems that the max is 2147483647 .

    http://dotnetstep.blogspot.com/2008/08/jsonserialization-error-solution.html

    And please pay attention to the 'Remark' section in the following document.

    http://msdn.microsoft.com/en-us/library/system.web.script.serialization.javascriptserializer.maxjsonlength.aspx

     


    Microsoft Online Community Support
    Dienstag, 27. Juli 2010 08:54
  • Thanks for the feedback. I've tried various values, i.e. 50000000 and 2147483647. Just to test, I tried setting it as low as 500 to see if a standard working operation would error out, but that did not. That was what lead me to believe the value in my web.config file was just being ignored. Also, I can confirm that we do explicitly create an instance of the JavaScriptSerializer class.
    Mittwoch, 28. Juli 2010 22:36
  • Hi,

    It's very interesting. Can you share the relevant configuration in web.config. If I had an idea ,I will response it as soon as possible.

    Thanks.


    Microsoft Online Community Support
    Donnerstag, 29. Juli 2010 01:16
  • Hi,

    Here are the relevant sections in my web.config file

      <sectionGroup name="system.web.extensions" type="System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
       <sectionGroup name="scripting" type="System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
        <section name="scriptResourceHandler" type="System.Web.Configuration.ScriptingScriptResourceHandlerSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication" />
        <sectionGroup name="webServices" type="System.Web.Configuration.ScriptingWebServicesSectionGroup, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
         <section name="jsonSerialization" type="System.Web.Configuration.ScriptingJsonSerializationSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="Everywhere" />
         <section name="profileService" type="System.Web.Configuration.ScriptingProfileServiceSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication" />
         <section name="authenticationService" type="System.Web.Configuration.ScriptingAuthenticationServiceSection, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false" allowDefinition="MachineToApplication" />
        </sectionGroup>
       </sectionGroup>
      </sectionGroup>
    

    and farther down is where I have

     <system.web.extensions>
      <scripting>
       <webServices>
    	  <jsonSerialization maxJsonLength="50000000" />
       </webServices>
      </scripting>
     </system.web.extensions>
    
    Thanks
    Donnerstag, 29. Juli 2010 15:34
  • Thanks for the feedback. I've tried various values, i.e. 50000000 and 2147483647. Just to test, I tried setting it as low as 500 to see if a standard working operation would error out, but that did not. That was what lead me to believe the value in my web.config file was just being ignored. Also, I can confirm that we do explicitly create an instance of the JavaScriptSerializer class.

    I believe the behavior your are describing is "just the way it is."  Reviewing this docs page:

    http://msdn.microsoft.com/en-us/library/system.web.configuration.scriptingjsonserializationsection.maxjsonlength.aspx

     

    I see in the remarks section that "The value of the MaxJsonLength property applies only to the internal JavaScriptSerializer instance that is used by the asynchronous communication layer to invoke Web services methods."

    If I'm reading that correctly, that means that only web methods (not MVC action methods) will observe the value set by the maxJsonLength property.  If that's the case, I suspect this is an oversight on behalf of the ASP.NET MVC team--I can't imagine why wouldn't want the Controller.Json(objectToSerialize) method to also use the maxJsonLength method.

    As a workaround, you can do the following:

                JavaScriptSerializer serializer = new JavaScriptSerializer();

                serializer.MaxJsonLength = Int32.MaxValue; // Whatever max length you want here

                var resultData = new { Value = "3", Text = "MD" }; // Whatever value you are serializing

                ContentResult result = new ContentResult();

                result.Content = serializer.Serialize(resultData);

                result.ContentType = "application/json";

                return r;

     

    Then you have the option of creating your own helper methods and/or result types to wrap that up into a convenient package.  For instance, you could create a "LargeJsonResult" class that inherits from ContentResult, and takes the result object as a constructor parameter.  Then, in your action methods, you can simply do: "return LargeJsonResult(objectToSerializeToJson);"


    -jb
    • Als Antwort markiert AHuang3545 Freitag, 13. August 2010 22:37
    Donnerstag, 12. August 2010 13:35
  • Thank you for pointing us in this direction. We have gotten past the issue now.
    Freitag, 13. August 2010 22:38