Applications built with the SOAP Toolkit or XML Web services are built according to the SOAP specification. With SOAP-based applications, the connection between a client and a Web service is defined exclusively by the WSDL file. A Web service built with the SOAP Toolkit can be used with a Web service built with .NET and vice versa. This allows you to migrate from the SOAP Toolkit to .NET in stages by holding the WSDL definition of the service constant. For instance, the clients that access your Web service can continue to use the SOAP Toolkit's SOAPClient while your Web service is converted to .NET.
The simplest way to hold the WSDL file for your Web service constant is to generate the skeleton for your Web service from the WSDL file created by the SOAP Toolkit. The .NET Wsdl.exe utility will generate the Visual Basic .NET skeleton for a Web service if you pass the utility the:
- /l parameter: Controls the language of the generated code. The default is C#. Passing /l:VB causes the utility to generate Visual Basic.
- /server parameter: Indicates that you want the utility to generate the Web service’s server-side code. The default is for the utility to generate the client-side proxies.
- The name of the WSDL file.
To generate the code for our sample Web service from the Cust.wsdl file, you would use:
wsdl.exe /l:VB /server cust.wsdl
The resulting skeleton code would be placed in a file called Cust.vb. You can copy the code from there into your ASMX module and then copy your Visual Basic 6.0 code into the equivalent routines in the ASMX module. You’ll need to convert your Visual Basic 6.0 code to .NET syntax, as described in other papers in this series. If you want to create a completely new .NET version of your Web service, the WSDL file from your SOAP Toolkit version can be used to generate the skeleton code for your Web service.
On the client side, the different client applications that access a Web service can be converted from the SOAP Toolkit to .NET on an individual basis. Even rolling out the .NET versions of a single client can be staged because of the interoperability that the SOAP specification provides. To convert from the SOAP Toolkit to Visual Studio .NET within the client, you must replace the references to SOAPClient with references to the Web service proxies.
Referencias SOAP Toolkit a :NET
http://www.dotnet247.com/247reference/a.aspx?u=http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnsoap/html/stkmigration.asp
http://dev4net.com/blog/archive/2005/02/16/1988.aspx
http://blogs.msdn.com/rdias/archive/2004/06/02/147128.aspx
http://msdn.microsoft.com/webservices/building/soaptk/default.aspx
Referencias de Interop
http://www.programmersheaven.com/2/vbrad-Interop
http://www.codeproject.com/dotnet/nettocom.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconapplyinginteropattributes.asp
Some important info related to MSXML :
SDK:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmsxml/html/joyofsax.asp
Support:
http://support.microsoft.com/search/default.aspx?catalog=LCID%3D1033&mode=s&cat=false&query=MSXML&srch=sup&x=11&y=12
MSXML2 will work if you point %TMP% to a writable location