SOAP Toolkit or COM Interop?
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 ...
... 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.