Alright, there was a delay (probably moderation) in my reply and I haven't seen your guys' posts until today.
I was about to reply by saying that creating the proxy class didn't work so well because all proxy classes supposedly must include a [WebServiceBinding()] attribute in the CodeDOM (above the class). But once that is compiled in, its static again and as far as I know can't be changed. I guess I'll use the WebRequest and WebResponse classes. One question about those though: do they work asynchronously? On Sep 10, 1:47 pm, Cale <[EMAIL PROTECTED]> wrote: > Thanks a ton Joe. I'll give that a shot, it sounds promising. I don't > know why I didn't think of that, lol. > > Thanks to Cerebrus too for the alternative method of calling web > services using HttpWebRequest and HttpWebResponse. Will those methods > work asynchronously though? > > Thanks again, > Cale > > On Sep 10, 10:52 am, Joe Enos <[EMAIL PROTECTED]> wrote: > > > In my implementation, I use a WSDL-generated codefile as a base class, > > named MyService_Base. In its constructor, it has the following line, > > representing wherever it pulled the info from: > > this.Url = "http://www.url.com/servicename.asmx";; > > > I then have a non-auto-generated codefile with class named MyService, > > that derives from MyService_Base. In this class, I have a new > > constructor that sets the Url property to whatever's in my config > > file. I use this class to compile and run against. This same > > technique can be used, with a new constructor that accepts the service > > URL as a string at runtime. > > > As long as your class derives from SoapHttpClientProtocol and have all > > of your logic there, you should be able to manipulate the Url, method > > names, and event handlers all at runtime. > > > On Sep 9, 11:53 pm, Cerebrus <[EMAIL PROTECTED]> wrote: > > > > Joe... I wasn't aware of this... can you elaborate upon how the URL of > > > a webservice instance (using the Proxy class method) can be > > > dynamically changed during Runtime? > > > > On Sep 10, 11:45 am, Joe Enos <[EMAIL PROTECTED]> wrote: > > > > > If I understand your issue, you just want to call a web service method > > > > without pre-compiling the signatures for the methods. This shouldn't > > > > be a problem. If you take a look at the auto-generated code after > > > > running WSDL on a sample service, you'll see what a request actually > > > > does - just calls things like: > > > > return this.BeginInvoke("MyMethodName",, new object[] {...) > > > > and other methods for each method in the web service. You should be > > > > able to set the Url property at runtime, and call the appropriate > > > > methods yourself, just by passing in the method name and parameters. > > > > > On Sep 9, 1:46 pm, Cale <[EMAIL PROTECTED]> wrote: > > > > > > Hello group, > > > > > > I've been digging around Google and the rest of the Internet for the > > > > > last few days trying to figure out how to consume a web service > > > > > without using a proxy class. Everything that turns up uses some type > > > > > of proxy class and that won't work for me... mainly because I won't > > > > > know the endpoints or web services to consume until later during > > > > > runtime. > > > > > > I've been porting some Java code related to web services recently. In > > > > > the Java code there's calls into Apache Axis to get the job done (for > > > > > both providing and consuming). Is there anything similar to that > > > > > in .NET? Or Is there at least some type of SOAP client class I can use > > > > > to create and send a request in .NET? > > > > > > Perhaps I should focus my searches on SOAP instead of "Web services"? > > > > > > Thanks in advance.- Hide quoted text - > > > > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DotNetDevelopment, VB.NET, C# .NET, ADO.NET, ASP.NET, XML, XML Web Services,.NET Remoting" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://cm.megasolutions.net/forums/default.aspx -~----------~----~----~----~------~----~------~--~---
