Thanks.
I re-added the web service. No help.
It may help to know that I am accessing the web service via a Windows
control hosted in IE.
In it, I dynamically set the web service url via a public property. Could
this problem be related to a difference in the build between when I added the
web service with a local reference and the build on the web service in our
test environment?
It didn't seem to matter before this. In fact, it was working just fine in
our test environment last week, but this morning crapped out with no known
changes.
It seems possible that there's an error being hidden by the html response,
but because the client expects xml, it hides it with another error.
Is there somewhere I need to explicitly set the response content type,
possibly as an attribute or a web.config entry?
> Hey Mike
>
[quoted text clipped - 9 lines]
>
> -Ravi Singh
Christoph Schittko [MVP] - 29 Dec 2004 03:52 GMT
Mike,
Your best bet is to get to the text of the error message. Since it's
html formatted it should be easy to read. If the returned error message
is the html error message from ASP.NET then it means something isn't set
up correctly at your web server.
Have you tried putting a tracing tool like tcpTrace [0] between your
user control and your web service? Since you mentioned that you are
reading the URL from a config file it should be easy for you to point
the client to the trace tool. The tool will then reveal the HTML
response of the server and get you on your way to troubleshoot the
problem. Note that you have to remove the trace tool once you fixed your
problems because WSE takes offense at the URL in the HTTP header not
matching the <To> SOAP header [1].
HTH,
Christoph Schittko
MVP XML
http://weblogs.asp.net/cschittko
[0] http://www.pocketsoap.com/tcptrace/
[1] http://weblogs.asp.net/cschittko/archive/2004/05/24/140906.aspx
> -----Original Message-----
> From: Mike Z [mailto:MikeZ@discussions.microsoft.com]
[quoted text clipped - 40 lines]
> >
> > -Ravi Singh
Mike Z - 29 Dec 2004 21:27 GMT
Thank you for the help.
This is what it turned out to be:
The html response occurred because my web service threw an unhandled
exception. Not good! And because (I guess) it's hosted by IIS, IIS decided
to return the error as HTML, as is the usual.
I finally uncovered the original exception, re-coded to handle ALL exceptions
(I actually caused the exception in an exception handler!), and
now everything is good in web services land.
Thanks again for your help.
> Mike,
>
[quoted text clipped - 71 lines]
> > >
> > > -Ravi Singh