9

If my contract looks as follows:

[OperationContract]
void DoSomething(int id, out string moreInfo);

this ends up looking like:

string DoSomething(int id);

when you import a web service reference. Is it possible to influence the auto-conversion of the order of the parameters? It was already surprising to find all out-parameters at the beginning of the function signature, but that was still workable, but we'd like void-methods to continue being void-methods. Or is this a SOAP limitation?

Abel
  • 56,041
  • 24
  • 146
  • 247
  • 1
    In this instance, a void method with a single `out` parameter is effectively a non-void method with the correct return value. What does defining an `out` parameter give you that the non-out version doesn't? – Adam Houldsworth Jul 02 '12 at 13:50
  • @AdamHouldsworth orthogonality in the design of the web services. We originally had services that returned a value and ones that didn't. However, each service was refactored to return statuses. By forcing the extra param, the build will automatically fail and we know what to fix where, plus that it's simply convenient to always know that the first param is an out-param that contains the statuses, regardless the rest of the contract. – Abel Jul 02 '12 at 14:10
  • 3
    I'm actually very surprised and impressed that WCF was able to generate a proxy for that operation at all! What is the rationale for using an `out` parameter in the first place? – MattDavey Jul 02 '12 at 14:10
  • 2
    @Abel Personally I would have just created a contract return that contained the status and packaged the data with it. I tend to avoid C# features when creating web service methods. So far as I'm aware, whatever options you get on the reference creation screen are the only available options for controlling the proxy generation. – Adam Houldsworth Jul 02 '12 at 14:12
  • 2
    @MattDavey it is not uncommon to have out-parameters. This is not a C#-only feature, it's even more common in other languages (C++ for one), and in IDL it is very normal to have `[in]`, `[out]` and `[in, out]` parameters. The use-case/reason is usually that you need multiple unrelated return values, in this case a status and result set. – Abel Jul 02 '12 at 14:27
  • @Abel it **is** quite uncommon in C# - particularly in WCF service contracts. I understand the need for them in C++ and why they are useful in many languages, but your question is not tagged C++. Idiomatic C# would not use out parameters for this purpose. – MattDavey Jul 02 '12 at 16:28
  • @MattDavey I would love to see an authoritive reference on your claim. Surely, when both WSDL and WCF decide to support it, there must be a use-case (like my current one) where it is hard or tedious to use another approach than out-params. I agree that it is probably not a very common need. – Abel Jul 02 '12 at 16:49
  • @Abel [here's one reference](http://msdn.microsoft.com/en-us/library/ms182131(v=vs.100).aspx). I'm not saying there's no use case for it, what I am saying is that using `out` parameters is not recommended or idiomatic in C#. Given that you have arrived here and asked this question, It seems you're already starting to run into the kinds of problems that led to this common recommendation. – MattDavey Jul 02 '12 at 17:18
  • @MattDavey: that's a general rule, not a WSDL or WCF rule. Compare `int.TryParse` and you know that MS themselves don't always follow their own rule (and there are many such examples). I agree, that there are limited scenario's for `out`-parameters in C#, but in some scenario's you _should_ use them. – Abel Jul 03 '12 at 08:00
  • @Abel agreed and I have conceded that there are times when `out` parameters are appropriate. My point is that WCF service contracts are certainly not one of those times. – MattDavey Jul 03 '12 at 09:30

1 Answers1

4

It appears to be based on a WSDL limitation: http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/48b5992f-f7bd-4b67-8299-514d1780fa9a

WSDL does not show the original method signature; instead, it shows the input parameters as a group and the output parameters as another group.

The limitation of not being able to separate return values from out parameters is in the WSDL. But that would mean the limitation of a void method would be part of svcutil.exe I think. There's no reason why there can't be a switch on svcutil to not move the first output to a return value, but that would be a request for a feature on ms connect.

Rather than void, you could return a simple status int or bool if your issue is consistency, but I'm sure that's not a perfect answer if you already have dozens of methods.

b_levitt
  • 7,059
  • 2
  • 41
  • 56
  • 1
    I happened upon the same link a few minutes ago. Indeed, it is a limitation of the underlying WSDL, it seems. The wrapper could use, of course, any order, but I don't see a use case for forcing that. We'll work around the limitations, then, at least we'll use a VoidResponse type to make refactoring easier for the time being. – Abel Jul 02 '12 at 15:07
  • Good idea on the VoidResponse type. – b_levitt Jul 02 '12 at 16:27