In ASP.NET Web services, there's no need for such a distinction. Simply return what you have to return, and it will be sent as part of an XML SOAP message. If an error occurs, just rethrow the exception (or directly don't catch it at all, and the same SOAP message will now contain an exception result (XML, obviously) instead. On the client side, most toolkits (other than .NET, I mean), will translate such a response into a an exception again. .NET proxies will allow you to catch a SoapException in these cases, so you have a familiar programming model always: try..execute..catch. That's all. Of course, as Web services are about XML and SOAP, that's what is going to travel through the wire ALWAYS. No objects there, they're generated by the proxies (client-side) and ASP.NET (server-side).
Related Q&A from Daniel Cazzulino
Here Daniel Cazzulino explains how to load a DSL (domain specific language) domain model instance file programmatically. This requires the .NET type ...continue reading
Here we offer a glimpse at 12 of .NET development expert Danny Cazzulino's top ASP.NET questions and answers.continue reading
C# developers should NOT be modifying InitializeComponent method in the code-behind (or any of the variable definitions) by hand.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.