I have a web service method where I would like to throw some custom exceptions e.g. SomeException, SomeOtherException etc which the web service would then turn into a SOAP fault which the client would be able to handle. In Java I can have wsdl:fault elements within the wsdl:operation element in the WSDL. It appears it .NET that this is not catered for and that there is no way of putting attributes on a WebMethod to show what SOAP faults may occur.
If I create a Java web service which has wsdl:fault elements and add a web reference to a .NET project I would have expected the wsdl:fault elements to cause appropriately named exceptions to be created just as the other entities are created, this however does not seem to be the case.
Is it the case that wsdl:fault elements in a WSDL are completly ignored by .NET? They are part of the WSDL specification defined at http://www.w3.org/TR/wsdl so this wasn't the behaviour I was expecting.
If this is the case possible work arounds might be returning a result object which contains a success/failure boolean value and an error message/enum. Or by using SoapExceptions. If I choose to use SoapExceptions I am then putting the emphesis on the user of my web service to handle these and deserialize it properly. Both of these don't seem a great way of handling this and add extra problems and code to workaround this.
Since you ask for .net 2.0 i guess you know that this is "fixed" in WCF where you can add the attribute [FaultContract(typeof(YourCustomException))].
The "normal" way this was done in 2.0 is as you says, add a Response message with a success-boolean, Result and a Error property.
You can typically see how this is done in EntLib.