If you have the requirement to consume a Web service from unmanaged/native code (like VB 6.0), your first thought might be to use the same tool we've used to do this for years: The SOAP Toolkit. Don't! As you can see from this link ...

http://www.microsoft.com/downloads/details.aspx?familyid=c943c0dd-ceec-4088-9753-86f052ec8450&displaylang=en

... support for this is going away in just a couple of months. Extended support until March '08 means there probably isn't even a whole individual responsible ONLY for high-impacting security-related hotfixes.

So what do you do? My recommendation is to just write the client in managed code and access it via COM interop. Naturally, you'll have to deploy the .NET Framework to the client, which might be something you hadn't planned for. But Don, what about the performance overhead of COM interop? Well, the SOAP Toolkit was never written with performance in mind so it is quite likely that you'll get performance just as good even with the COM interop. Also, the Toolkit doesn't support the WS-I Basic Profile by default so it makes sense that you'll get much better Web service interoperability with .NET and COM interop. Just don't use the SOAP Toolkit - it has a very grim future.