Just curious: whatever gave you the idea that you needed a single-threaded COM Server on the web? The biggest drawback of a single-threaded server is that it will not scale at all and, if you have more than 1 user on the web(which is very likely), they'll be waiting around for results.
You'll be using the more streamlined runtime for a vfp mtdll, but, I really don't see any disadvantages to using it, only advantages. A vfp mtdll will scale with multiple users on the web and present a responsive web application, be it a web service or regular web app.
Some of the early MS web service examples made a big mistake by saying to compile to a Single Threaded dll. But, if you look at all of the latest VFP9 web service examples, they're all created as VFP mtdlls. The latest versions may be a little faster, but, I've found the VFP5SP6 vfp mtdlls to be very stable...
>We are trying to create an instance of a VFP 6 SP5 COM object from a .NET web service. It wasn't working, and I found some articles about web services being multi-threaded, and can't automatically use single-threaded COM objects. So I recompiled our COM object as a Multi-Threaded COM Server, which seems to now be creatable from our .NET web service. I also saw that there is a way to create the single-threaded COM object by using the System.Threading namespace, but I haven't tried that yet.
>
>My question is this: Are there any drawbacks to compiling the COM object as multi-threaded, or should I look into the System.Threading method of calling the single-threaded COM object?
>
>Thanks,
>Jonathan