Extender web service method is called differently

For a reason i do not understand, i have a web service which the the signature corresponds to what it is supposed to be (I see the signature everywhere) and this extender calls a completly different web method signature...

The extender is the cascading drop down list extender, it is supposed to call :

Public

Function GetDropDownContents(ByVal knownCategoryValuesAsString,ByVal categoryAsString)As AjaxControlToolkit.CascadingDropDownNameValue()

But instead it calls :

Public

Function GetDropDownContents()As AjaxControlToolkit.CascadingDropDownNameValue()

What this does is that it prevents me from knowing what values where already selected. Usually, this could be done by parsing the knownCategoryValues but since i don't get this param anymore, i'm a bit clueless at how to do this.

Can anyone help me understand this problem?

Hi,

I think ASP.NET AJAX will actually fail if it can't find a matching signature (this includes correctly cased parameter names). I'm guessing something else is the culprit here. You might want to take a look at your CascadingDropDown declaration to make sure it's calling the web service you're expecting (and when in doubt, compare against the sample website).

Thanks,
Ted
The problem is not the source or the function being called cause if you read what i said again, it is triggering something in the right web service, it's just not triggering the right function... and to fix the error 500 i had earlier i have to create a parameter less web method which is completly useless in this case...

Exposing web service that returns DataSet

Hi,

Is there anyway to call web service(asmx) method that returns DataSet from client javascript that uses

AJAX <ScriptManager> (that generates auto js proxy) , I know that custom classes works as a return value, what about DataSets?

If Yes I can I process those DataSets , in client callback functions?

TNX

Leeor

leeorc

dont know if you can do this and whether it is an issue for you but if you do move to datasets then you will be restricting your web service to .net consumers only

http://weblogs.asp.net/infinitiesloop/archive/2006/12/14/ajax-futures-december-ctp-returning-datasets-datatables-and-datarows-from-a-webservice-or-pagemethod.aspx

Exception has been thrown by the target of an invocation.

I have an Atlas enabled asp page working fine in Visual Web Developer 2005.

It has a Web Service with two methods one for an autocomplete and another to generate a datatable to populate a datagrid.

The second method makes calls two methods from a DataSet object.(one gets a row and the other its details.)

When I deploy to produccion the autocomplete works fine but populating the datagrid fails with:

Exception has been thrown by the target of an invocation

thrown by InternetExplorer.

I tested the Web Service calling its operations directly and it works fine.

Please help.

ps. the production machine has low space in C:\ drive.

In both cases I go against the same SQL Server 2000 database.

Since I posted the question above I was able to "deploy" to a Virtual Directory (called "LocalAtlas" situated on D:\VB Projects\VB Web Developer\Atlas Web Virtual Dir\ ) of my Local IIS and after I added the impersonation tag

<

identityimpersonate="true"userName="vvvvvvvv"password="pppppppp"/>

the page worked as expected. However, it is looking for the .asmx file in the same directory where Visual Studio looks.

But changing the KEY tag from

<

addkey="OBWebServiceRef.OBWebService"value="http://localhost:1459/AtlasWebSite1/OBWebService.asmx"/>

as created by Visual Web Dev to

<

addkey="OBWebServiceRef.OBWebService"value="http://localhost/LocalAtlas/OBWebService.asmx"/>

or anything else I can think of (in Web.config) does not work.

(I removed the fileAtlasWebSite1/OBWebService.asmxto avoid using it)

Exception Handling?

It looks like there's no handling for server side errors at this point at least for the Web Service behavior. If I do the following:

[WebMethod]

publicbusCustomer GetCustomer()

{

thrownewSoapException("Failure dude!",SoapException.ServerFaultCode);

returnnewbusCustomer();

}
The call simply doesn't complete to any of the callbacks. Is there anyway to get any error info out of this? It seems to me that the result values should either include some sort of complex object that contain a reference to an error object or else provide some sort of other mechanism that notifies you of an error. Instead of a Timeout method, maybe there should be a more general Error method with an error object you can query for what type of error occurred on the server.

Hello

Try this on the client side javascript:

function displayTimeout(result)

{

alert('timeout:\n' + result);

}

function dispalyError(result)

{

alert('error:\n' + result);

}

function callMyWebservice()

{

GetCustomer(CallbackMethod,displayTimeout,displayError);

}

You can also use Fiddler to view the data returned from the Webservice. (www.fiddlertool.com)

Hi,

following the suggestion given by donaldduck1312, you have to declare an error callback for the asynchronous request. When the callback is invoked, you receive a Web.Net.MethodRequestError instance as the first parameter; this object has methods that allow to display infos about the error:

function onError(e) {
alert('Server Error: ' +
e.get_exceptionType() + '\r\n' +
'Message: ' +
e.get_message() + '\r\n' +
'Stack Trace: ' +
e.get_stackTrace());
}

Exception Handling

I haven't found any documentation on how to handle exceptions. Right now, I am throwing a System.Exception in the web service on purpose. I don't seem to be getting a result in javascript. Are there any examples for handling exceptions?
Wally

Exception handling is also very important for me. - Definitively missing. Glad to see a timeout feature !

Yes, it's one of the things that are missing right now. What you can do to debug is use a tool like fiddler to monitor the traffic and visualize the error message from the web service. Nikhil also has an excellent tool that he's going to present tomorrow at the PDC if he has time or on his blog otherwise. Stay tuned...
In which session will the tool be shown?
CIAO
Michael

It's not only while developing and debugging where you need exceptions. Many regular situations can be handled more effeciently using them.

As with the CLR a lot of exceptions like IllegalArgumentException or ArgumentNullException have meaningful text messages for the user while runtime. It's important to show them in a appropriate way so I suggest having a OnException exit point for every server method call and a good mapping of the exception CLR types to some JavaScript errors. I haven't found a good solution for this yet.

I think we need something similar like the .error property I have added in Ajax.NET Professional. Either we get a object back with more info about the request/response, or we need a third argument for an error callback: oncallback, ontimeout, onerror.
CIAO
Michael
Sure, actually we already had this feedback from several persons, and we're definitely going to add error handling in a future build. For the moment, you can use a fiddler-like tool. Nikhil's presentation is tomorrow at 5:00PM.
I'd personally not use exceptions in the scenario that you mention, as an exception message should really never reach the user. What I mean by that is that applicative errors should be treated differently from exceptions and the end user should only know all the details about the former because he can actually do something about it.
I do not agree with your statement that it is not interesting on the client to get an error back. I think there are two different errors:
- one, that will occur on the .NET code and returns a System.Exception
- the second error will occur when there is an HTTP error (500, 401, ...)
Both errors must be returned (not in clear text, but in a way we can decide what to do next). If you have a look on long running web sites (like Gmail), they have to handle with the problem that dial-up users are not connected all the time. In this scenario we need to get an error.
CIAO
Michael

bleroy wrote:

an exception message should really never reach the user...

I don't want to start a religious programming style war here. I've seen both opinions and the all where reasonable in their cases.
We will get "errors" on the client when in offline mode or disconnected. These states we have to handle with. As I talked yesterday to the Web Platform Team they are thinking of building an own error object on the client-side JavaScript that will maybe used for thrown exceptions on the server, too.
<BLOCKQUOTE><table width="85%"><tr><td class="txt4"><img src="http://pics.10026.com/?src=/Themes/default/images/icon-quote.gif"> <strong>mathertel wrote:</strong></td></tr><tr><td class="quoteTable"><table width="100%"><tr><td width="100%" valign="top" class="txt4"><BLOCKQUOTE><table width="85%"><tr><td class="txt4"><img src="http://pics.10026.com/?src=/Themes/default/images/icon-quote.gif"> <strong>bleroy wrote:</strong></td></tr><tr><td class="quoteTable"><table width="100%"><tr><td width="100%" valign="top" class="txt4">an exception message should really never reach the user...</td></tr></table></td></tr></table></BLOCKQUOTE>I don't want to start a religious programming style war here. I've seen both opinions and the all where reasonable in their cases.</td></tr></table></td></tr></table></BLOCKQUOTE>
Me neither. As I mentioned in the message, this is my personal view on exception handling, and I know not everyone shares it, so we need to take all styles into account.
<BLOCKQUOTE><table width="85%"><tr><td class="txt4"><img src="http://pics.10026.com/?src=/Themes/default/images/icon-quote.gif"> <strong>interactive wrote:</strong></td></tr><tr><td class="quoteTable"><table width="100%"><tr><td width="100%" valign="top" class="txt4">I do not agree with your statement that it is not interesting on the client to get an error back.</td></tr></table></td></tr></table></BLOCKQUOTE>
Never said that. I was talking about exceptions, not errors. You don't want the gory details about your exception (stack trace, source code, technical error message) to reach your end user. It's useless to him and it's a security risk. That's the reason for the customErrors setting in ASP.NET for example. Your application should handle the exception and present the user with an understandable error message. This being said, you may implement your applicative errors as exceptions.