We Keep Coding

WCF SOAP Web Service Handling Bad Enums - C# .Net

I have a WCF SOAP Web Service built using svcutil to generate the contract classes. The WSDL has enums and thus the default is to deserialize the XML to an enum class. This works great when the user sends in the correct enum.
<priceType>List</priceType>
<priceType>Net</priceType>
However, if the user enters a bogus value:
<priceType>I love dogs</priceType>
The deserializer throws and exception and they get a SOAP Fault that there was a server error. How could I respond with a better error message that their enum value is invalid?

c#: How to consume webservice methods whose address is unknown at compile-time

I am consuming a webservice from a Java server. The webservice provides me with some methods that need. Up till now I have been using the method where I added the reference of the webservice in the project explorer, typed the address of the webservice and compiled it. But now I need it to pick up the address of the service at runtime from an xml file or something! is that possible?

There is Url property in generated proxy object that you can set at runtime. Covered in Creating the Web Service Proxy article on MSDN.
Sample from the article (shows how to also set credentials, you may also need to set Proxy):
var rs = new ReportExecutionService();
rs.Url = "http://<Server Name>/reportserver/reportexecution2005.asmx?wsdl";
rs.Credentials = System.Net.CredentialCache.DefaultCredentials;
Note that above answer is for case when you don't know exact Url of server till runtime, but you have WSDL/sample server available at design time and able to generate proxy via add web service in VS (or manually).
Alternatively you can call service via other classes implementing "HTTP GET" like HttpClient and configure anything you want, but will need to do your own parsing of results.

C# Web Service client that will fail if WSDL is not available or invalid

My client hosts a few web services and has ASP.NET Web pages that will demo the web service and acts as a quick check to verify that the web service is up by the client. The problem is that the WSDL might be missing or invalid, but the Web Service will still work.
What I'd like to add to the ASP.NET web service client is a way to verify that the WSDL is there and valid, but have no idea where to start. Any suggestions would be greatly appreciated! Code behind is C#

I'm not entiery sure what you mean with verify that the WSDL is valid. Only thing I can suggest is, use an HttpWebRequest on the specific URI and see what response you get then either throw an exception based on specific status codes like 404 for example or handle it in a different way.
You can fetch the status code value
var request = (HttpWebRequest) WebRequest.Create("http://example.com/service.wsdl");
using (var r = (HttpWebResponse) request.GetResponse())
{
var result = r.StatusCode.ToString() == 200.ToString() ? "Success" : "Service not found";
Debug.WriteLine(result);
}
Hope this helps, goodluck.
Edit: if you know what services you're going to be testing you can simply add them as service reference in your client project and try to do an RPC on the service methods to see if it's available. Pictures below show to add a service reference.

Your scenario doesn't completely make sense. You could make a request to the service WSDL endpoint, http://something/service.asmx?wsdl and you could confirm that what comes back is a WSDL file. You could even validate it against the WSDL and XSD schemas.
This wouldn't tell you whether it was a WSDL that represented the service. It could conceivably be a WSDL for some totally different service.
Maybe more importantly, have you had problems where the service was available but the WSDL was not? In that case, rather than create diagnostics, I recommend that you fix the problem.

Make a single WCF service support both SOAP, REST and WSDL

I'm trying to build a C# service in .NET 3.5 that supports both SOAP - and shows the WSDL - and REST.
The SOAP service and WSDL generation was easy enough to do using the ServiceHost and a BasicHttpBinding classes. Got that working and the client was happy.
Because the SOAP calls all used simple parameters, the client developers requested a REST interface for some of the commands. So I changed the ServiceHost class to a WebServiceHost, added necessary WebInvoke and WebGet attributes, added a WebHttpBinding class, and bingo - REST and SOAP were both working out of one service. Way cool, change one interface and both REST and SOAP got the new stuff.
But one problem - the WSDL no longer gets generated. I couldn't browse to http://server/service?wsdl and get the WSDL file. Checking the MSDN docs, that appears to be behavior for a default WebServiceHost.
Question: can I override this behavior so that the WSDL could be obtained? Doesn't have to the same URL as before - it can change - but I just need to have some URL into service to get the WSDL for those SOAP developers.

When you say "added a WebHttpBinding class", it sounds like you are doing a lot of the configuration in code as opposed to in configuration files.
If this is the case, you could try moving the configuration to the configuration file. Then create 2 endpoints for the contract one REST and one SOAP, with 2 different addresses and bindings.

But one problem - the WSDL no longer
gets generated. I couldn't browse to
http://server/service?wsdl and get the
WSDL file. Checking the MSDN docs,
that appears to be behavior for a
default WebServiceHost.
Yes - that's one of the drawbacks of REST - no more WSDL, no more machine-readable service description. You need to hope the service provider gives you a usable and up to date documentation on what you can do.
There's no WSDL for REST - period. Can't be turned on or anything - it just doesn't exist.
There are some efforts under way to provide something similar - called WADL (Web Application Description Language), but as far as I know, it's still far from an established standard by any means. Also see: Do we need WADL?

Circa, 2007, WSDL v2.0 is supposed to be able to describe RESTful services. I have found that with WCF in .Net v4.0, that the WDSL generated from a purely RESTful service is invalid (WSDL v1.0?).
I created a similar project that exposes both SOAP and RESTful endpoints, and enabled this by, as you did, modifying the interface as such:
// Get all Categories - complex object response
[OperationContract] // categories
[WebGet(BodyStyle = WebMessageBodyStyle.Wrapped, UriTemplate = "GetAllCategories")]
CategoryCollection GetAllCategories(); // SubSonic object
[OperationContract] // categories - respond with a JSON object
[WebGet(ResponseFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Wrapped, UriTemplate = "GetAllCategories.JSON")]
CategoryCollection GetAllCategoriesJSON(); // SubSonic object
One caveat to this is that all input parameters now must be of type string for all SOAP requests.
Any way of getting around this?

Getting an Instance of your Web Service Reference

So I believe all you have to do with .NET 2.0 vanilla web services (not WCF) is the following:
1) Add your service reference. In my case I'm using the PayPal WSDL
2) Before you can use any proxy class, you must first create an instance of your service reference
3) Once you create an instance of your service reference, then just do [servicereference].ProxyClassName.Method or whatever you're trying to access from those classes
right?
Ok, so I tried that. I added a service reference and named it SandboxSoapAPI. So that's what you see under references in my C# project.
In code I tried this:
SandboxSoapApi reference = new SandboxSoapApi();
but it doesn't recognize SandboxSoapAPI. Am I doing something wrong? I just want to start calling class methods, etc. with PayPal and I can't seem to get this right.
And if I'm not incorrect, as of .NET 2.0+ it handles the low level sending of the actual request over Http for SOAP web service references?

SandboxSoapAPI is not the SOAP client proxy type name. It's a namespace.
To check this, in VS.NET tick 'show all files' and drill into the Web References, open up the Reference.cs file, you will see the SandboxSoapApi is a subnamespace (not your SOAP client proxy name!) in the project's root namespace.
So either use the fully qualified name:
SandboxSoapAPI.YourProxyType client = new SanboxSoapAPI.YourProxyType();
Or use using SandboxSoapAPI; in your code where you need the SOAP client.