Sys.Res is undefined Sys.Net is undefined Sys.Application is undefined error ajax json

So, switching to RSH (Really Simple History) for Ajax history back button management I, all of a sudden, started getting the below errors -


Sys.Res is undefined
/ScriptResource.axd?d=pAszYI1Gb4SpsTh8sMT0W6wF1gtmVrXttUVRBvK-ueW1CPqT8yfJ7elHbLz7SUAEaufrYfuec4EOs8rqAu5Babg0xkVae2w4D2gBh1dvVuE1&t=ffffffffa3435222
Line 2798
[Break on this error] if (typeof(val) !== 'number' || ...dOperation(Sys.Res.enumValueNotInteger);

Sys.Net is undefined
[Break on this error] BlahService.registerClass('BlahService',Sys.Net.WebServiceProxy);

Sys.Application is undefined
[Break on this error] Sys.Application.initialize();

Sys.Net is undefined
[Break on this error] BlahService.registerClass('BlahService',Sys.Net.WebServiceProxy);
jsdebug (line 61)
[Exception... "Component is not available" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: file:///C:/Program%20Files/Mozilla%20Firefox/components/nsSessionStore.js :: sss_saveState :: line 1908" data: no]
[Break on this error] this._writeFile(this._sessionFile, oState.toSource());


As you can see in the screenshot above as well, these errors are getting generated from inside ajax.net stuff and that's pretty much the most horrible source of errors/bugs thing that you can get! What I mean to say is that if the source of the error is some code written by some human, then it can be debugged and fixed but if the error is originating from some place like ScriptResource.axd?d=pAszYI1Gb4SpsTh8sMT0W6wF1gtmVrXttUVRBvK-ueW1CPqT8yfJ7elHbLz7SUAEaufrYfuec4EOs8rqAu5Babg0xkVae2w4D2gBh1dvVuE1&t=ffffffffa3435222 then there's squat you can do to fix it! And even more so when one of the errors seems to say Sys.Application.initialize(); then you know that you are doomed!

Anyhow, after lots of caffeine, anguish and praying finally the Lord Google revealed the answer - Turns out that Microsoft's Ajax.net is not compatible with JSON (JSON being used by RSH - Really Simple History plugin)! Go figure! Some little proof-of-concept showed that yes if I get rid of the ScriptManager control (that ships with Microsoft's Ajax.net) toolkit then all those errors will disappear.

<asp:ScriptManager runat="server" EnablePageMethods="true" ID="BlahScriptManager"
EnableHistory="true" EnablePartialRendering="true" EnableStateHash="false" OnNavigate="BlahScriptManager_Navigate">
<Services>
<asp:ServiceReference Path="~/DynamicUpdater.asmx" />
</Services>
</asp:ScriptManager>


So we are talking about either getting rid of JSON or getting rid of ScriptManager control (or both for that matter!) as possible solutions. RSH (Really Simple History) unfortunately relies on JSON and all of my asynchronous ajax (web service) calls rely on using ScriptManager with EnablePageMethods set to true (with the webservices referenced in the Services as you can see in the above code). Both RSH and the asynchronous calls (Webservice through the ScriptManager) are integral for the system but since Microsoft ajax.net won't play with JSON, I'm scr-wed. But I guess we are all here to do what we are all here to do and I'll be implementing all the asynchronous webservice calls with regular XMLHttpRequest and I'm guessing that it might even give some little performance boost given Microsoft Ajax's ScriptManager control is rather heavy duty stuff.

Update: Dec 29 2008: I successfully implemented the aforementioned functionality, it turned out to be a much better option than using ScriptManager/ASP.net/Ajax and it didn't require a lot of extra code either. Read more here - Calling Webservices from jquery using JSON