Not all code paths return a value?

Discussion in 'ASP .Net Web Services' started by Bruce W.1, Dec 11, 2003.

  1. Bruce W.1

    Bruce W.1 Guest

    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.
     
    Bruce W.1, Dec 11, 2003
    #1
    1. Advertising

  2. Bruce W.1

    Colin Savage Guest

    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" <> wrote in message
    news:...
    > 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, Dec 11, 2003
    #2
    1. Advertising

  3. 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" <> wrote in message
    news:...
    > 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.
     
    Dino Chiesa [Microsoft], Dec 11, 2003
    #3
  4. Bruce W.1

    Bruce W.1 Guest

    "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_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.
     
    Bruce W.1, Dec 12, 2003
    #4
  5. Bruce W.1

    Colin Savage Guest

    "Bruce W.1" <> wrote in message
    news:...

    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
     
    Colin Savage, Dec 12, 2003
    #5
  6. > > 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.


    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.
     
    Dino Chiesa [Microsoft], Dec 15, 2003
    #6
  7. Bruce W.1

    Colin Savage Guest

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

    Colin

    "Dino Chiesa [Microsoft]" <> wrote in message
    news:Ogeo%...
    > > > 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.

    >
    > 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, Dec 17, 2003
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    679
  2. Noah
    Replies:
    5
    Views:
    790
  3. Greenhorn
    Replies:
    15
    Views:
    833
    Keith Thompson
    Mar 6, 2005
  4. process
    Replies:
    1
    Views:
    319
    Terry Reedy
    Oct 4, 2008
  5. Ohad Lutzky

    Paths, gentleman, paths

    Ohad Lutzky, Nov 6, 2006, in forum: Ruby
    Replies:
    2
    Views:
    201
    David Vallner
    Nov 7, 2006
Loading...

Share This Page