Thanks!
JoeI had Tech Support give me admin privileges and the AJAX extensions installed without a problem. Apparently the installer was getting confused...it normally reports that sort of thing when Admin is required on an install.
i have a production server that I am attempting to install AJAX on. I have installed the latest release .msi file and I have the 2.0 framework running on it. do I need to do anything else? Here is the error I am getting when I run my sites that contain ajax controls...
Description:An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.
Parser Error Message:Could not load file or assembly 'Microsoft.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified. (C:\wmpub\WMRoot\web.config line 53)
Source Error:
Line 51: </httpHandlers>Line 52: <httpModules>Line 53: <add name="WebResourceCompression" type="Microsoft.Web.Handlers.WebResourceCompressionModule, Microsoft.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>Line 54: <add name="ScriptModule" type="Microsoft.Web.UI.ScriptModule, Microsoft.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>Line 55: </httpModules>
I have read a few postings about similar errors, but have had no luck when following the steps. Is there a "step by step" list on how to install AJAX on a production server? Thanks in advance!
Nathan
This is what i think, your project is using old AJAX dll
because by looking at Microsoft.Web.Extensions in the web.config
The Microsoft.Web.Extensions is not for latest AJAX
the latest AJAX is using "System.Web.Extensions"
In the web.config should be like below
<httpModules>
<add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</httpModules>
so you have either version conflict or web.config setting is incorrect
Thanks for catching that... I had not updated by web.config... stupid error. I appreciated it!
Nathan
We have been using our own (non fancy) ajax framework till now. Now that Microsoft itself published these controls I thought of checking them out.
The first thing is the much talked about UpdatePanel.
I noticed when some client interaction happens the Panel actually calls the Page_Load event every time including initialization of variables. It basically loads the entire code behind page (class) instead of just calling the method which should have been written to be self sufficient like a Web Method in web services. This is like let the server reload the page but the client will get only filtered content.
Is this how AJAX works? If so I have never seen a technology which such a big blunder being accepted so fast.
Its a known fact that the page load is used to load content into the page so if it calls this event it would also get all the datasources even though the ajax function does not deserve it.
This shall never work in an enterprise scenario.
Atleast just like isPostBack there should have been an isAjaxPostBack so that we can avoid reloading unwanted stuff. Even having a provision for a separate page would do.
For those of you who develop enterprise applications please develop your own frameworks.
To recreate this scenario:
Do a Debug.WriteLine under Page_Load Event and run in debug mode. You can try calling some private methods in Page_Load and having Debug.WriteLine there too. You would be surprised that these events are called though the update panel requires the event which happened inside of it.
ASP.NET AJAX partial postbacks work with Page.IsPostBack in the same way that a full postback would.
antonpious:
Atleast just like isPostBack there should have been an isAjaxPostBack so that we can avoid reloading unwanted stuff. Even having a provision for a separate page would do.
What aboutIsInAsyncPostBack property of the scriptmanager? 
What aboutIsInAsyncPostBack property of the scriptmanager?
Yes this seems to have solved the problem of code structure and can prevent unwanted methods from being called.
with this type we now have to code like this on the Page_Load
!isPostBack && !scriptManagerInstance.IsInAsyncPostBack
isPostBack && !scriptManagerInstance.IsInAsyncPostBack
!isPostBack && scriptManagerInstance.IsInAsyncPostBack
Still it does not stop it from initializing the entire controls in a page together with global variable declarations. They have cleverly hidden the designer when using the default web project but if you installed VS 2005 SP1 you can create a web project which creates a designer file with all the controls present in a page. Typically the pages would be pressed for realestate with every available space being used. Loading all the controls when a partial render is required does not scale. This when compounded with initilization of Typed DataSets as DTO is bound to be a big failure. We then have to go back to implementing classic OOPs with classes as DTOs.
Still it does not stop it from initializing the entire controls in a page together with global variable declarations
Partial page rendering works this way, check the doc:Partial-Page Rendering Overview, from that page:
"An asynchronous postback behaves much like a synchronous postback. Allthe server page life-cycle events occur, and view state and form dataare preserved. However, in the rendering phase, only the contents oftheUpdatePanel control are sent to the browser. The rest of the page remains unchanged."
"An asynchronous postback behaves much like a synchronous postback. All the server page life-cycle events occur, and view state and form data are preserved. However, in the rendering phase, only the contents of theUpdatePanel control are sent to the browser. The rest of the page remains unchanged."
Thanks for your inputs.
Yes it sends the contents of the UpdatePanel together with changes to the ViewState, but lets say if I have 50 controls (textboxes, dropdownlist etc) not to mention global variables in a page out of which the UpdatePanel has 10 why does these 50 controls have to be loaded on the server side and then filtered to get content for the 10 controls UpdatePanel to be sent to the client browser. The problem becomes bigger as more and more controls are added to the page.
Guess now that the source code is available this has to be extended to have the content come from a separate page.
1. If your code wasn't using IsPostBack to avoid reinstantiating unneeded objects on every postback, it probably didn't scale without AJAX either anyway.
2. If you want a leaner way of implementing ASP.NET AJAX callbacks, check out web methods (not web services). You don't have to use the UpdatePanel. It's just the training wheels they give us to get started with.
Hi,
Just to inform you that Asp.net Ajax Framework is not about Update Panel.
Asp,net Ajax Framework there are two development model:
Server Centric or UpdatePanel
I appreciate your passion.
easy to make an ajax version of a page without writing a single line of code.
yes this is why we are in this profession. Its one thing making life easy and another thing tricking us into it.
The sample that came with AJAX 1.0 should have included the details of how it works together with what stmarti pointed out. The Page_Load event should have had the if statements to distinguish what code is called with AJAX. I am pretty sure many out there would not have made the 3 part distinction. I assume they did this to make your "no single line of code" compliant.
We are not comparing web service. If you have written your own AJAX framework, one way to do it is to call a separate page with the required information with a seed to prevent caching in browser. This returns the xml or html markup which is used by the client side to populate the partial rendering div element. We are not talking about 1000 of lines once the functions are in place no one needs to write the code again just like you are doing with this framework where all the scripting is done by Microsoft.
If you are really wants to develop an enterprise level application follow the Client Centric Model. FYI Both Live.com and Pageflakes.com are developed in MS Ajax and they are serving millions of users each day following the Client Centric Model
With regard to the live.com I have seen so many of you who fall for this trick. This was there even at the time of hotmail when they said hotmail is written in PERL so its Enterprise specific.
Please understand that the web technology is not about a particular technology its about the combination of technologies. You may not know how many servers live.com is run on to get that speed you are talking about.
Even the maintainers of this forum had to add extra servers and hardware to take care of the load.
The point is if there is a flaw it has to be told upfront not hidden in fine print.
You can continue to use it but do understand its limitations.
If you have written your own AJAX framework .
I am not sure did you mean to create a Framework from Scratch or a Framework which works on top of MS Ajax? Certainly you can create your application specifc frameowork which does lots of plumbing things for you. But if your are recommending to develop a framework from a scratch then it is nothing but a poor advice.
With regard to the live.com I have seen so many of you who fall for this trick. This was there even at the time of hotmail when they said hotmail is written in PERL so its Enterprise specific.
Th reason behind mentioning the two sites was to inform you that it is possible to develop large application with Asp.net Ajax. Certainly there are lots things behind the scene including load balancing which makes the application scalable.
The point is if there is a flaw it has to be told upfront not hidden in fine print.
You can continue to use it but do understand its limitations.
I think you are again stuck with the UpdatePanel. Ms Ajax is not about the Update Panel. If you are following it from beta version the Client vs Server centric development model has been discussed so many times in different articles and blog posts. Of course you have to know the ins and out of a technology for a successful implementation and this applies to all including MS Ajax.
But if your are recommending to develop a framework from a scratch then it is nothing but a poor advice.
It again goes back to the common saying "Web Services is not SOA" but "what is left of SOA if we remove Web Services".
Here is a comparison of the coding that was done to make both your Client and Server Centric Models.
Used by xml-script a Client-Centric model
AtlasUIMap.js
containing 823 lines of code with some lines extending to 2168 character and single alphabet variables with a file size of 105KB
Not to mention the code added by xml-scipt block. With xml-script accepted by many as not an easy language to master.
used both by Client-Centric and Server-Centric
Atlas.js - Atlas Framework
AtlasRuntime.js - Atlas Runtime Framework
containing 11392 lines of code with a file size of 360KB
This throws a challenge if anyone can write a framework with less number of code. Since the framework one writes is customized to a single system without having to take all parameters into consideration it would always outsmart MS AJAX.
Hi,
I am a big fan of using 'Update Panels'. Not because of the only simplicity but also bcoz of my belief on the AJAX framework.
But, at the same time lots of architects do say that, PageMethods [http://metasapiens.com/PageMethods/Tutorial/VS2005/] are more efficient than Update Panels.
Here is the link - ASP.NET AJAX UpdatePanels are dangerous.
http://encosia.com/2007/07/11/why-aspnet-ajax-updatepanels-are-dangerous/
After reading the page, I am quite suspicious on Update Panel and now think that really PageMethods saves perfomance overhead.But at the same time, simply by going thru few pages, accepting the same seems to be quite impractical.
Please let me know, is really PageMethods are more efficient than UpdatePanel. If yes, then please list me the things that cannot be done using PageMethods, which can be done by UpdatePanel.
Regards,
Arun
Hi,
dangerous is itself dangerous word in this context, but truth is that UpdatePanels, by design and due to their nature, pass a lot more stuff over the wire than PageMethods. Remember, they pass the changed markup, ViewState etc over the wire.
What the article/post says about it is true. However, it is always context dependant, is it an issue. Is the Page so big that async postback with UpdatePanel is unbearable? There are also ways to optimize things like reducing the unneeded ViewState, using multiple UpdatePanels to split the page to as-small-as-possible regions which need to be updated using UpdatePanel. E.g update only the parts which really need to be updated instead of passing everything you have on the Page. Using one UpdatePanel for entire page for example is not wise, if the page can be split up.
using multiple UpdatePanels to split the page to as-small-as-possible regions which need to be updated using UpdatePanel. E.g update only the parts which really need to be updated instead of passing everything you have on the Page. Using one UpdatePanel for entire page for example is not wise, if the page can be split up.
I think it's important to keep in mind that even if you do break the page into multiple UpdatePanels, the entire ViewState is still sent to the server. On top of that, the Page and every single control in its control tree is reinstantiated, even if you're only visibly updating a tiny portion of the page.
The overhead associated with this can be relatively massive.
It would be nice to see if UpdatePanel could evolve so that its child controls would have viewstate field of their own (one per Panel), however that brings a lot complexity to the picture (especially from MS perspective) but also for developer to be explicit which Panels access each others child controls (that's why page now loads entire state because it must assume any control could be accessed).
While I'd use PageMethods too mostly today, I also like easiness of UpdatePanels and look for its evolution in vNext (meaning the one after Orcas/2008)
hello.
well, lets be honest: the updatepanel is a beautiful piece of engineering. having said that, i think that ajax is mostly done on the client, so major js,css, xml, etc is required. I'm not sure if changing viewstate is the way to go here. i'm thinking that what should be changed is the way we, developers, face our projects...
Sample question : Is Atlas js framework cached by browser ?
Thanks !
ClémentM
hello,.
this should happen if you don't have the debug=true on the compilation element of your configuration file.
There is a really valuable tool available for watching HTTP traffic in real time.
http://www.fiddlertool.com/fiddler/
This tool will let you watch all incoming/outgoing traffic and you can put breakpoints on the traffic and "fiddle" with it. Hope it can be of use to you!