ASP.net AJAX and precompilation

I often will precompile an application so that I can get better performance on my production servers. However when I mix it with AJAX, it goes bad.

I run from a VS.net Command Window:

aspnet_compiler -p "C:\documents and settings\mandreko\my documents\visual studio 2005\websites\ajax_maillist" -v /maillist c:\maillist

I then copy the c:\maillist to my websiteroot/maillist and get this error:

Server Error in '/maillist' Application.

---

Object reference not set to an instance of an object.

Description:Anunhandled exception occurred during the execution of the current webrequest. Please review the stack trace for more information about theerror and where it originated in the code.

Exception Details:System.NullReferenceException: Object reference not set to an instance of an object.

Source Error:

An unhandled exception was generated during the execution of thecurrent web request. Information regarding the origin and location ofthe exception can be identified using the exception stack trace below.

Stack Trace:

[NullReferenceException: Object reference not set to an instance of an object.]
 System.Web.Script.Services.WebServiceData.GetWebServiceData(HttpContext context, String virtualPath, Boolean failIfNoData, Boolean pageMethods) +368
 System.Web.Script.Services.PageClientProxyGenerator.GetClientProxyScript(HttpContext context, IPage page, Boolean debug) +46
 System.Web.UI.ScriptManager.RegisterServices() +748
 System.Web.UI.ScriptManager.OnPagePreRenderComplete(Object sender, EventArgs e) +242
 System.Web.UI.Page.OnPreRenderComplete(EventArgs e) +2012740
 System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1566

If I run the non-precompiled version of the code, it works perfectly on my production server, however when trying to precompile it, it causes this. Any ideas on this? Are they not compatible? Am I missing something?

Hi,

I'm still learning about AJAX, but it could be that your problem is do to the way caching is handled in each instance. Perhaps the precompiled version is using cached data, while the on-demand model is getting fresh data. I do know that caching is a concern for AJAX enabled applications, and that just turning cahing off is not a workable solution.

For a pretty good run down on how the two development models (Websites, and Web Application Projects), handle compilation, take a look at this learning video from the Learn tab here at asp.net:http://asp.net/learn/videos/view.aspx?tabid=63&id=16 This vid covers the WAP add-in (which is no longer needed as an add in after you do the VS 2005 SP1 install). Towards the end there's a good slide showing compilation choices and paths.

Hope it helps BRN..

Actually after searching some more, I found it. Looks like it's a known problem:

http://forums.asp.net/thread/1499979.aspx

At least now I know I'm not crazy.

Hi,

Glad you found out what was causing the issue - hope the thread provided a solution or work around. BTW, did you do the VS 2005 SP1 install yet? I was wondering if that would address the problem you ran across.

So, you think one problem explained proves you're not crazy? Hummm. Let's hope your right! As an admitted lunatic, I wouldn't worry about it in any event. BRN..

VS 2005 SP1 didn't fix anything unfortunately. I did have that.

It matches my problem description, and even got ScottGu posting about it, so I'm confident they'll have it fixed in the next release.

ASP.Net 2.0: Does using an UpdatePanel reduce back-end server load?

Hi there,

I have been experimenting with the AJAX Extensions for a while, and I have been looking at performance and other related characteristics of AJAX-izing my controls.

One question that came to mind is whether an AJAX-enabled control can reduce the back-end processing load. It might have been published somewhere before, so I apologize for the repeat in that case.

I noticed that when the client causes an AJAX postback through an UpdatePanel, it seems that the server would reload the entire web form and all its components/controls, but just sends the new UpdatePanel content back to the client. While this most certianly reduces egress, the back-end processing cost is not reduced. And with the help of AJAX controls, people tend to put more content on the same page. And in an obscure way, it actually increases server load, because the cost to refresh a portion of the page is computationally equal to a full refresh of the page, which is now more expensive because we put more content in a single page (i.e. more DB hits, etc).

I reckon that there might be documented ways to indicate that a custom control is somewhat "independent" in that a refresh does not require new data outside of the control itself (e.g. a custom control that just updates the current time every time the user clicks a button), but I haven't found any yet. Ideally, this control can live in a complicated page that requires several DB hits to refresh, but it would be great to have a way where a refresh postback to this AJAX control would cause the server to only execute the code of this control, and not re-process the entire page and incurr several extra DB hits.

If anyone knows of any such tricks or guidelines, I would really appreciate it if you could share. :-)

Thanks in advance,
- K.

hello.

well, the only way you have to build controls that integrate into ASP.NET and that are refreshed without full postbacks is to use the ICallbackEventHandler interface that was build into ASP.NET. btw, I'm not sure that you'll be gaining much by using this approach, but it exists.

regarding your remarks, what I can say is that web built AJAX pages will have most of their load in the client side, and will only use web services (or handlers) to get its data from the server side. This means that you'll have lots of JS to write, but again, that is why AJAX has a J, right?

Yes the UpdatePanel does not reduce the Server Load. Instead it offloads the data transfer of the wire and you should properly use it. To create more scalable application you can choose the Cient Centric Development Model but in that case you may have to write quite a lot of JavaScript depending upon the applicaiton you are building.

Regarding the ICallback of the Control also executes the full life cycle of the page. Moreover it only supports string for request/response as there is no serializer which does not do the conversation which is the case of Asp.net Ajax.

Thank you Kazi, I think this concurrs with my thinking and I appreciate your help.

However, others please chime in if you have other comments or nifty tricks that I can use.

Thanks,
- K.

Asp.net & Microsoft Ajax Performance issues

I am having performance problems with ajax control toolkit. I have a web form with some ajax control toolkit controls(Textbox, Dropdownlist) and some simple standard asp.net controls. Now whats hepening with me whenever I post a ajax call to server each time request size increases secondly all the data of controls of the page is being sent back to server on each request why?

If I do all this work with raw javascript using XMLHttpRequest object(the very first form of ajax) it works fine.

Hi,

According to your description, I think it's normal to see this.

When you use ASP.NET AJAX, it doesn't eliminate unnecessary data transfer. All information on current page will be posted to server just as a normal request.

While working with a raw XmlHttpRequest, you can send necessary data explicitly.

you are right its normal way of httprequest.

But my point is, don't you think for a specific control say a button or text box only required data(viewstate) should be travel to server as you can do using simple ajax.

I think if this functionality could be added in Ajax Framework it will be a value added in this framework for enterprise applications wehere performance is critical.

Yes, this is a good point.

But we have to sacrifice some performances when we manage to achieve an easy-to-use framework. This sacrifice usually comes with UpdatePanel, but if you are accessing WebService or PageMethod, there will be less unnecessary traffic.