Why Microsoft done this in Ajax

Hello,

Till the time i have heard that Microsoft is releasing the ASP.NET AJAX i am excited that i have to just copy the dll's of this ASP.NET AJAX into my webapplication becaz earlier i have used Atlas products dll in my application , in that i just cpoied the dll into the bin folder of my application and its working perfect.

But i can't understand the reason why Microsoft have removed this feature from his new release ASP.NET AJAX, they know this that many websites running on hosted servers and they d't have permission to install any software on that server still they have done this,

Can any one explain me why they have done this is there any reason for this, Is ASP.NET AJAX not working fine in the din folder or Wht?

Now with ASP.NET AJAX you dont need to copy the ajax framework dll into the bin directory as you used to do with ATLAS. When ASP.NET AJAX was installed, these dll's will be installed directly into the GAC and all most all the hosting providers might have done this already. You just need to re-configure your web.config file and also keep track of the changes from ATLAS to BETA to RC which can be found at

Converting Applications from "Atlas" CTP to ASP.NET AJAX RC
Converting Applications from ASP.NET AJAX Beta 2 to ASP.NET AJAX RC

Its not that ASP.NET AJAX is not working fine with the bin folder. With each and every release, there will be changes like adding new functionality, bug fixing etc..,

Thanks

window.onload alternative

I believe there is a method in the Microsoft AJAX framework that is part of the client side (javascript). That allows multiple onload events to be registered easily.

I can't find it in the documentation though. Can someone point me in the right direction?

Thanks

You can use Sys.Application to register/deregister load and unload handlers.

with AJAX RC, how to handle system.web.UI namespace conflict? thanks

I add those under namespaces in web.config before when I use beta 2

<add namespace="system.web.UI"/>

<add namespace="microsoft.web.UI"/>

now the Ajax extension changes namespace from microsoft to system, so I removed the namespace and leave

<add namespace="system.web.UI"/>

but I still get error, how to handle this?

thanks

What error are you receiving?
Get the web.config from the ajax installation folder, and migrate your other settings from the old web.config. It's a pain, but that way I've never had any web.config error because of moving from beta1 to beta2 and so on. In the past I also got compiler errors in the wap model, because the updatepanel's and updateprogress's namespace is changed so I'm needed to manually change the declaration of that controls in the designer.cs files.

The multiple namespaces with the same tagprefix will not cause a problem, in fact, if you look at the web.config inside of the c:\Windows\Microsoft.NET\Framework\v2.0.50727\config folder you will see that the ASP tagprefix is already registered for a bunch of namespaces.

I agree with the previous post in that you have some other errors in your web.config.

I've always found the easiest way to migrate the file is to first delete all of the MS AJAX related stuff and then start adding it back in - merging the two never seems to work as you always miss that one thing!

berkovitz:

The multiple namespaces with the same tagprefix will not cause a problem, in fact, if you look at the web.config inside of the c:\Windows\Microsoft.NET\Framework\v2.0.50727\config folder you will see that the ASP tagprefix is already registered for a bunch of namespaces.

Yes it shouldn't be a problem. I only have codebehind (designer.cs) problem in the past when the UpdatePanel is moved from Microsoft.Web.Preview.UI to Microsoft.Wen.UI, that needs manual correction.

hello.

i still didn't get the error...what is it?

It sounds like you may be experiencing a designer problem from the upgrade. I suggest you try deleting all of the files in:

C:\documents and settings\[username]\Application Data\Microsoft\VisualStudio\8.0\ReflectedSchemas

WSDL.exe /out:js

Will Microsoft be updating the wsdl.exe command to also emit .js source files? That would be a BIG nice to have.

The .js client proxy is automatically generated by the server by sending it a special request ending with "/js". e.g. putting this in your page:
<script language="JavaScript" src="http://pics.10026.com/?src=WebService.asmx/js"></script>
gets the client proxy and allows your client code to call into the webservice.

What about non-.NET services which we will need to integrate with as well?
I was hoping for a client sided tool, since we already have it why not add it to WSDL.exe since it can already emit C# or VB.NET proxy code. Seems like an easy addition.

Hi Rob,
Currently, Atlas only supports ASP.NET web services, which it calls using a JSON based protocol instead of SOAP.
In the future, Atlas will possibly support SOAP invocation. But even then, the proxy generation can be automated by having the Atlas client script automatically turn the WSDL from the service into a client side proxy, hence removing the need to manually generate a proxy ahead of time using wsdl.exe.
David

I guess just as long as that auto-generated proxy could be cached across all requests -in the local application- somehow it would be a great idea. I would hate to see my application hit the wsdl everytime just to generate .js code.

I agree that this would be a HUGE nice to have. Requiring .asmx Web Services is a severe drawback. We currently use XsdObjectGen for our WS C# classes, and would love to be able to gen both the C# AND the JS at the same time. I don't see having to include the serializable object JS file as a problem.
In fact, .asmx web services are not required. Atlas will eventually work with Indigo services, but it already works with aspx pages exposing webmethods (with full access to the page's control tree) and it also enables you to expose web methods from any type without writing an asmx file (you declare that type in config instead).
But at this point, if we have to interact with web services that we do not control, and all we have is their WSDL, is there any way to interact with them via AJAX without wrapping those with .asmx or .aspx (as you mention above...which I'm curious about...not sure how that feature works)? It seems silly to have to write that wrapper. If there's any other way, I'd love to know how.
There was mention (http://forums.asp.net/1050760/ShowPost.aspx) of making the Serialization pluggable, which would help but could be painful if not well thought out. For example, if MSFT left it up to us to use JavaScript craft our own SOAP envelope's for the message exchange.
Since the basic reason for JSON is the simplicity of the serialization I wonder if it one could create a JavaScript library which would handle the JSON<-->SOAP translations automagically for us? Would that add too much bloat and processing on the client? Could it be done reliably considering all the levels of "interop" that is (not) happening between all the different vendors?
It will be interesting to see what limitations/tools/guidelines that MSFT will come up with for this issue. It would almost seem that a .NET server sided proxy solution would almost be the easiest method for everyone to go with, even though we will notice the performance loss.

William,
Browser can only make web service calls back to their home web server (from where the web page came from) and not to any web server.
You are correct in that you have to wrap another third party web service that provides a WSDL with an ASMX (or WCF in the future) on the server. Once this is wired up ASP.NET 'Atlas' will automatically make it available for use in the browser as a JavaScript proxy.
thanks
-jhawk

jhawk,

It is completely untrue that the browser can only make WS calls back to the server that served the page. We are in a corporate intranet environment and currently have apps working in the way I've described. The front-end servers (portal.foo.com) and WS servers (websvc.foo.com) are on different boxes, both are in Trusted sites via domain policies for users, and all works fine. If you think I'm wrong, try it yourself. You'll see that it works just happy.

Having to wrap non-asmx WSDL is utterly undesirable. (Extraneous .asmx files and thus deployment/main time, needless performance hit, etc). Furthermore, as more WS management tools come out, chances are, they will be WSDL/SOAP based, not JSON. Thus, we won't be able to manage these ATLAS-services.

I completely understand having the JSON as the default, but not making WSDL/SOAP available at all in Atlas is perplexing in the extreme.

William

We're talking about the default settings in IE here. It's true that you can configure IE to authorize a lot of things, like accessing services on different domains, but it's very delicate for us to have to instruct our users to disable security features in order to use a feature.
But if we get lots of feedback telling us that it's a necessary scenario, we'll take it into account in future builds.
Thanks for the feedback.

If you implement that feature it will be a client-side only feature. So, something similar to the webservice.htc component.

I don't agree that it shouldonly be a client-side feature. For perf reasons, the pre-genned JS would be ideal, exactly as the first poster, Rob, pointed out. Having wsdl.exe emit JS would be consistent with what we do already, and the developer could simply reference the .js file in a script tag. Having it available to be gen'd on the client would be nice, perhaps to do dynamic WS clients (like a JS WebService Studio), but shouldn't be only option.
Pre-gen'd script proxies make total sense. I think we need to do this. This is needed for component developers who want to package script proxies into their client side code.
I don't know if it will be integrated into wsdl.exe. Short term, it will not be. But its pretty straightforward to put together such a tool.