A while ago We encountered a technical problem with Ajax.Net Pro.
The problem is fully described in here but the short story was that after we did all we can to create an application that does not maintain any state on the server side, it seemed like Ajax.Net was doing just that, and in doing so throws an exception:
{"Message":"This method is either not marked with an AjaxMethod or is not
available.","Type":"System.NotSupportedException","Stack":null,"Source":null}
This would happen when a an application running while a new version deployed on our server and then an Ajax call was made to the server.
luckily for us just a few days ago the code for the current Ajax.Net was made public by its creator Michael Schwartz.
Having the code available we quickly found out that the problem was that since we where using a "WebSite" .Net project in our development, each time the assembly was compiled it got a different name, something like "App_Web_59e2jzgq.dll", this is serialized to the client and used on the call back.
The solution to the problem was to move to Microsoft's new yet old Web Application project model.
The migration process is explained quite well in here:
http://webproject.scottgu.com/CSharp/Migration2/Migration2.aspx
This causes the assembly name to loose its random part and thus can be referenced again by the information serialized to the client even after re-deployment.
(of course you have to make sure your interfaces remain compatible.)
Monday, September 18, 2006
Ajax.Net Pro: System.NotSupportedException exception.
Subscribe to:
Post Comments (Atom)
1 comment:
Hi,
there is a great feature to use your own paths instead of the temporary assembly name path, see my blog at:
http://weblogs.asp.net/mschwarz/archive/2006/09/18/How-to-prevent-System.NotSupportedException_3A00_-This-method-is-either-not-marked-with-an-AjaxMethod-or-is-not-available.aspx
CIAO
Michael
Post a Comment