Question

[NOTE:I am really looking for some good debugging techniques here. Perhaps some tricks or ways to simplify things of which I am unaware.]

I am using the technique of calling [WebMethods] defined in an ASPX page from JQuery as mentioned here and here. It seems to be an increasingly common method.

I’ve been using it for a while and, in general, it works great. But while developing it is pretty fragile. Any incorrect parameter will result in a really vague, non-specific, error message. For instance, if I have a fairly complex web method defined as:

[WebMethod]
public static string SaveComplexRecord(int recID, GeneralData general, SomeObject data, SomeOtherObject moreData)
{
   //do a bunch of stuff with that data
}

And GeneralData, SomeObject, and SomeOtherObject all have a mix of various types of parameters (strings, ints, bools, datetimes.) It is very likely, especially during initial development, that I will build the JSON on the client side incorrectly. Perhaps I will do this:

var data = {
    recID: curID,
    general:
    {
        a: aValue,
        b: bValue,
        c: cValue
    },
    data:
    {
        d: dValue,
        e: eValue,
        f: fValue
    },
    moredata:
    {
        g: gValue,
        h: hValue,
        i: iValue
    }
};

Which will result in an error because the name of the third parameter is moreData, not moredata. And that’s just an example, there could be any of a hundred other subtle typo-style errors.

If I were calling this method from C# the compiler would give me an error message something like “No overloaded method of SaveComplexRecord takes three parameters.” or some other helpful message that points you in the right direction.

So… is there a way of getting ASP.Net to produce better error messages here?

Or is there some utility that will automatically build the JSON parameter structure of a [WebMethod] call? (just like you can automatically get the WSDL of a web service)

…or any other technique that I may be missing?

And for completeness here is how I call these WebMethods from JQuery:

   var jsondata = $.toJSON(data);

    $.ajax({
        type: "POST",
        url: "MyWebPage.aspx/SaveComplexRecord",
        data: jsondata,
        contentType: "application/json; charset=utf-8",
        dataType: "json",
        beforeSend: function(xhr)
        {
            xhr.setRequestHeader("Content-type",
                         "application/json; charset=utf-8");
        },
        success: function(msg)
        {
            //do something on success
        },
        error: function(XMLHttpRequest, textStatus, errorThrown)
        {
            alert("ERROR status:" + textStatus + " error:" + errorThrown);
        }

    });

Answer 1

Or is there some utility that will automatically build the JSON parameter structure of a [WebMethod] call? (just like you can automatically get the WSDL of a web service)

Yes! The ASP.Net AJAX framework can do this! You could get the framework to generate client side proxy classes for GeneralData, SomeObject and SomeOtherObject classes using the ‘GenerateScriptType’ attribute on a web service class.
See understanding asp net ajax web servcies for a very good article about the subject.

[Unfortunately, AFAIAA, the GenerateScriptType has no effect when applied to the Page class where your page method is defined – so you will have to add an .asmx purely to get the proxy generation.]

You could perhaps use these classes to build up the data structure that you then JSON stringify when you call .ajax? [One of (the very few) things I really like about the MS AJAX framework is the client side proxy generation: it really does make calling web services and page methods very easy. Having said that, I too am moving towards using jQuery in preference to MS AJAX.]

Or alternatively…
Your problem is really that the de-serialisation of the JSON data into the arguments of your page method is done transparently by the framework (which in most cases is a good thing) but when it goes wrong, the feedback you get is less-than-helpful. If you want to trap de-serialisation problems then I think you have to take control of the serialisation either by using custom JSON converters (see here) or by using the rather inelegant sledgehammer approach of having your method accept a string and de serializing the JSN yourself in the method – which is trivial with anyone of the numerous JSON libs out there.