WebSvcs : Dynamic

Kant

Is there any way programmatically generating the proxy (that will the web service methods) instead of doing it by via 'Add Web Reference' or 'WSDL.exe'?
Promise only what you can do. And then deliver more than what you promised.
This signature was created by "Code Project Quoter".

Daniel Turini

Kant wrote: Is there any way programmatically generating the proxy (that will the web service methods) instead of doing it by via 'Add Web Reference' or 'WSDL.exe'? I don't know what you're trying to accomplish, but isn't easier to simply send/receive the SOAP message through HTTP? After all, it's just a bunch of well-documented XML... I see dumb people

Kant

Daniel Turini wrote: I don't know what you're trying to accomplish I am just curious. Other day I was talking to a friend who asked me this question. Ex: In a GUI application, let the user input the URL of the web service and based on that can we generate the proxy?
Promise only what you can do. And then deliver more than what you promised.
This signature was created by "Code Project Quoter".

Daniel Turini

Kant wrote: Ex: In a GUI application, let the user input the URL of the web service and based on that can we generate the proxy? You can always generate the proxy and compile it. But I think that the easier way would be reading the WSDL definition (after all, it's usually a really simple XML) and creating a SOAP message (another XML), then send it through HTTP. Probably you'll find some sample (not in .NET) that already does this... I see dumb people

Heath Stewart

Unless you want a typed web service proxy, you could extend SoapHttpClientProtocol (which generated web service proxies do by default) and instantiate that, either providing the URL to the WSDL document in the constructor or set the Url property (inheritted from WebClientProtocol) after instantiation. As soon as you call Discover to set up the bindings, you can use Invoke to invoke the methods you want. Invoke is protected, which is why you must extend the SoapHttpClientProtocol, but you could always expose an override as public if you wanted. You could do the same with the asynchronous protected methods (BeginInvoke and EndInvoke). Without knowing what the bindings are, however, this could get pretty messy. That's where the DiscoveryClientProtocol comes in, another derivative of the WebClientProtocol. From this you can get a DiscoveryDocument which you can use to discover the bindings supported by the web service. If you want to generate typed proxies, you can use the concepts presented above to do that. As I mentioned, the proxies extend SoapHttpClientProtocol and add methods for each of the bindings through discovery and simple call the protected Invoke to call them (or the asynchronous methods to support asynchronous methods on your proxy).

Microsoft MVP, Visual C# My Articles

jqd2001

Heath, Thank you for the great idea. I actually tried to extend SoapHttpClient as you said: public class MySoapHttpClient : SoapHttpClient { public string TestWebMethod() { this.Invoke("TestWebMethod", ...);} } and use it as MySoapHttpClient obj = new MySoapHttpClient(); obj.Url ="http://localhost/WebService7/Service1.asmx"; obj.Discover(); string s = obj.TestWebMethod(); It works fine. But I cannot replace the signaure "TestWebMethod" with a generic one "Invoke(string MethodName)". Does it mean that Binding must be reflected in the proxy ? Or there are some ways to go arround. James

Heath Stewart

You can, but you must hide the protected member by using new:

public new object[] Invoke(string methodName, object[] parameters)
{
return base.Invoke(methodName, parameters);
}

Microsoft MVP, Visual C# My Articles