Not all code paths return a value?

[Bruce W.1]

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/RSSviaXmlTextWriter.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.

 

[Colin Savage]

Even if your code compiled, I don't think a web service is what you are
wanting in this case. Web services send and receive SOAP messages, so even
if your web method returns an xml document/ string/ writer...whatever...it
will be wrapped in a SOAP envelope.

RSS on the other hand is xml written directly to the Response as shown in
the example link you provided. This is so that a RSS client can retrieve the
xml (document) from a url as RSS, not as RSS escaped inside a SOAP envelope.

I would suggest you read up on web services and RSS (basics of the HTTP
protocol would probably be a useful one to understand too)

Hope this helps
Colin.

 

[Dino Chiesa [Microsoft]]

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_11/magazine/columns/integration/dwahlin/default_pf.aspx

-D

 

[Bruce W.1]

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_11/magazine/columns/integration/dwahlin/default_pf.aspx

-D

===============================================================

Well then I guess I'm confused, and I forgot about the SOAP envelope.
What you say makes perfect sense.

An RSS feed should be just like a link to an XML file, only noone uses a
..xml extension it seems. And a web service uses SOAP.

However please look at this blog (which uses dasBlog):
http://www.hanselman.com/blog/
Click on any of the RSS buttons. It returns XML from a web service.
The parser in IE obscures the fact that there's a SOAP envelope right?
Is this then NOT a proper RSS feed?

Thanks again.

 

[Colin Savage]

snip

Well then I guess I'm confused, and I forgot about the SOAP envelope.
right.

An RSS feed should be just like a link to an XML file, only noone uses a
.xml extension it seems. And a web service uses SOAP.

this is because it is unnecessary. HTTP provides a content type header which
indicates that it is xml. the file extension is irrelevant.

However please look at this blog (which uses dasBlog):
http://www.hanselman.com/blog/
Click on any of the RSS buttons. It returns XML from a web service.

wrong. there is no indication that
http://www.hanselman.com/blog/SyndicationService.asmx/GetRss is a web
service. It is the content that counts, not the file extension. You could
have a url like this:
http://www.example.org/html.xml.pdf.rhubarb.fishpaste.yabba.dabba.do.txt
that returns a MS word document. THE URL IS IRRELEVANT. (except for with
some buggy versions of IE5)

The parser in IE obscures the fact that there's a SOAP envelope right?

wrong. There is no "soap parser" in IE.

Is this then NOT a proper RSS feed?

it is a proper feed.

Colin

 

[Dino Chiesa [Microsoft]]

However please look at this blog (which uses dasBlog):

wrong. there is no indication that
http://www.hanselman.com/blog/SyndicationService.asmx/GetRss is a web
service.

But, it is apparent that the given URL is invoking a method on an ASMX page.
In other words, it's a web service.

But WHY is there no SOAP envelope? This is because the ASMX is allowing
HTTPGET requests from IE, which specifically do not use SOAP envelopes.

Check the documentation page and examine the "sample" messages:
http://www.hanselman.com/blog/SyndicationService.asmx?op=GetRss

You can try this yourself by constructing an ASMX page and invoking it with
HTTPGET (eg, the test page). You will see no SOAP envelope.

 

[Colin Savage]

You are right, I am forgetting WSDL101, the "web service" can really be any
port binding, not necessarily soap.

Colin