Bruce, you asked in a separate post "Why return XML? Why not just use web
services?"
I think you got an answer to that one. RSS (as one specific case) is a
well-established standard. SOAP is another worthwhile standard. They do
different things. They are intended for different purposes.
The trouble you described in THIS post is because you have conflated both
approaches, inappropriately.
Programming to ASMX, you build a webmethod. Your webmethod should have a
return value, of a specific Type. On the server side, the instance of that
Type - in other words the return value of your webmethod - is magically,
transparently serialized to (converted to) XML, and then written to the
network.
[webmethod]
public MyType Method1() {
MyType i = new MyType();
return i ; // <<--------- results in i being magically serialized
to the "wire"
}
On the requester side, there is a client-side proxy, usually, that does the
converse operation. The xml data on the wire is magically, transparently
de-serialized into an instance of a Type. This is the web services model.
// client-side code - invoke a webmethod
MyType instance = MyServiceProxy.Method1(); // <<-- magically
deserialize from XML to object
The tooling and runtime helps you out by putting XML on the wire, and
pulling it off. By tooling I mean wsdl.exe, which creates client-side
proxies; by runtime I mean the ASP.NET ASMX support, which causes "return
i;" to result in XML being written to the network.
Now in the ASPX / XML model, YOU (the programmer) are responsible for
putting XML on the wire. YOU have to write content to
Response.OutputStream, and YOU have to be responsible to insure the output
is valid, well-formed XML, or whatever it is you are trying to return.
In general, your webmethods (approach #1) should NOT write to
Response.OutputStream (approach #2). You have to choose one approach or
the other.
The intent of my web service is an RSS feed from a blog. Originally I
used a StringBuilder to make the XML and returned a string from the
webmethod. But this doesn't display properly in IE. So now I'm trying
an XmlTextWriter instead.
What do you mean, "it doesn't display properly" ? what does it look like?
This makes me wonder what the return type for the webmethod should be, a
string, a HttpResponse, some sort of XML file, or what? This code
simply writes to the output stream. What return type is this?
Don't do this in a webmethod. If you want to return XML, then set the
return type to be System.Xml.XmlDocument or System.Xml.XmlNode .
Check this for a discussion of the topic
http://www.fawcette.com/xmlmag/2001_...efault_pf.aspx
-D
"Bruce W.1" <br***@noDirectEmail.com> wrote in message
news:3F**************@noDirectEmail.com... The intent of my web service is an RSS feed from a blog. Originally I
used a StringBuilder to make the XML and returned a string from the
webmethod. But this doesn't display properly in IE. So now I'm trying
an XmlTextWriter instead.
I whipped-up another webservice based on this:
http://www.codeproject.com/aspnet/RS...asp?print=true
This example isn't set up strictly as a webservice. It seems to output
to an aspx web page, not an asmx web service page. And this code has a
problem with the HttpContext.
Anyway, I put it in an asmx file so it can be called as a web service.
This makes me wonder what the return type for the webmethod should be, a
string, a HttpResponse, some sort of XML file, or what? This code
simply writes to the output stream. What return type is this?
And the problem I'm having is Visual Studio gives me this compile error:
...: not all code paths return a value (from the webmethod)
This is understandable because the Response.OutputStream sort of
bypasses the whole webmethod return type.
How should I fix this? Is there a way for the XmlTextWriter to write to
a string, then return the string? Is this the right solution to this
problem?
Thanks for your help.
