.NET Explorer offers the Load File Wizard that guides you through the steps required to load a WSDL file and invoke Web-service methods. To activate the wizard in .NET Explorer, click Start Here on the toolbar.
You can also load WSDL files, or .NET assemblies that contain .NET Remoting or other .NET classes, through the address bar of your browser. Specify the URL or path to the WSDL file and click Load.
Microsoft .NET Framework offers classes that load WSDL files and generate client proxies for Web services that are defined in WSDL files. .NET Explorer uses this functionality to generate C# or VB.NET code for Web-service proxies and compile the code into temporary .NET assemblies that are displayed as Web Service Proxies in .
As .NET Explorer uses Microsoft .NET Framework to generate proxies, .NET Explorer shares the drawbacks and limitations of Microsoft .NET Framework. The most significant problem when generating proxies is that not all SOAP stack implementations produced by other vendors comply with the W3C standard. This can lead to problems when you attempt to load WSDL files. You can avoid these problems by manually editing the WSDL files so that they are recognized by Microsoft .NET Framework. To edit the WSDL files you must be familiar to WSDL. For additional information, refer to http://www.w3.org.
.NET Explorer shows a Web-service proxy class, derived from System.Web.Services.Protocols.SoapHttpClientProtocol, in the References menu tree below the Web Service Proxies tree node. Normally, when you write C# or VB.NET code, you must instantiate an instance of the proxy class and call methods on the proxy. .NET Explorer eliminates the need for this by automatically instantiating an instance of the proxy class. You cannot create an instance of a proxy class by calling the constructor. .NET Explorer treats Web services like static objects offering static methods.
If the methods of a Web service take complex objects as parameters, then the classes of those parameters are defined in the WSDL file and loaded by .NET Explorer. Such classes are not Web-service proxy classes. They are simple classes with members and are listed under the Other Classes tree node in the Class menu tree.
You can set several connection-related properties by double-clicking a proxy class in the menu tree and opening the connection wizard in the Input Data Properties pane. These properties are set to the corresponding properties of the internal proxy instance.
When you export a project to either Visual Studio .NET or directly to Silk Performer as a .NET project, the base class of the Web-service proxy is replaced by SilkPerformer.SPSoapHttpClientProtocol. The reason for this is that by exchanging the base class, the Silk Performer .NET Framework is able to generate more detailed timers for Web-service calls that are routed through the Silk Performer Web engine. If you don't want this behavior you can export a project to Visual Studio .NET and either change the base class back manually or use the Web Service dialog box from the Silk Performer menu and deselect the option for routing the proxy class.
You can now either load the WSDL file of the Web service you want to test or select a WSDL file from the list box.