This is an exceptionally cool feature, since it effectively gets you out of having to deal with the horrifically complicated configuration involved in setting up WCF, just to get JSON to your client script.
Since web applications are becoming more client-script/web service oriented these days, I was curious at how well these kinds of ASP.Net applications would port to Mono. After all, with the economy being what it is, some companies are becoming interested in ways to continue to innovate while saving some money, and Mono runs ASP.Net on Linux.
In order to get started quickly, I got a copy of VMWare Player (which is free), and downloaded the VMWare image from the Mono project's web site for Mono 2.4. When I started the image, I discovered that everything I needed to start experimenting was ready to go out of the box. There were some samples, and a copy of the new version of MonoDevelop, just waiting for me.
The first thing I did was to create a new ASP.Net web project in C#, and create an asmx web service that would return a complex type of some sort, and then use JQuery on the Default.aspx to call the web service. I used the JSON2.js serializer on the client side to verify that the output by just deserializing it.
The initial results were a disaster. All I could get from Mono's asmx web service was XML output, despite putting the ScriptMethodAttribute on my web service method. ScriptMethodAttribute tells the asmx HttpHandler to output in JSON format.
Assuming (incorrectly, as I later discovered) that I had found a rather silly bug in the Mono class library, I tested the exact same code in Microsoft's ASP.Net...which proceeded to work as expected.
After a bit of a break, I started thinking about how, exactly, MS got the old asmx HttpHandler to output JSON without modifying the existing class library. After all, when the smart folks as MS started adding in the 3.0 and 3.5 class libraries, they vowed to not change the existing class library if it wasn't truly necessary.
I took another look at my web.config file in Visual Studio and discovered what magic made this possible:
<remove verb="*" path="*.asmx"/>
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=126.96.36.199, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
In Visual Studio, the default web.config unwires the old asmx http handler, then wires up a new asmx http handler that lives in System.Web.Extensions.dll. The old handler is still unaware of JSON, the new handler takes care of all of this instead.
The default web.config MonoDevelop created did not contain these modifications the the httpHandler section. Fortunately, everything about the <add> line was the same except for the assembly version (Really? You got the public key token the same but not the assembly version? Why?). Once I modified web.config, I got JSON output from the asmx.
I know not everything in ASP.Net 2.0 is working in Mono, but its really satisfying to see that the team working on it have implemented the parts that are most interesting to everyday web developers. I'm looking forward to seeing what cool bits the next release of Mono will bring.