By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,028 Members | 1,869 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,028 IT Pros & Developers. It's quick & easy.

Not all code paths return a value?

P: n/a
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.
Nov 12 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
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.

"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.

Nov 12 '05 #2

P: n/a
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.

Nov 12 '05 #3

P: n/a
"Dino Chiesa [Microsoft]" wrote:

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

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

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.
Nov 12 '05 #4

P: n/a

"Bruce W.1" <br***@noDirectEmail.com> wrote in message
news:3F*************@noDirectEmail.com...

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/Syndic...ce.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....a.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
Nov 12 '05 #5

P: n/a
> > 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/Syndic...ce.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/Syndic...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.

Nov 12 '05 #6

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

Colin

"Dino Chiesa [Microsoft]" <di****@online.microsoft.com> wrote in message
news:Og****************@TK2MSFTNGP10.phx.gbl...
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/Syndic...ce.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/Syndic...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.

Nov 12 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.