>But if the packages are exported to the web server, then the MTS/COM objects are running on the web server and not my COM server.

No, they are not. You are only exporting proxies. The COM component will still run on your server. Run the client setup on the web server, not the package install.

> The web servers will not be under my direct control most of the time. The COM and database servers will be.
>
>I am looking at VB for security because
>1. 99% of the ADSI examples from MS (and their WROX cronies etc) are in VB/script.
>2. A lot of the 3rd-party security providers that I will/might deal with (company is looking into outsourcing some of the user account and public key account management because some apps will have 5,000+ users) will be full of VB-ers and I don't have time to educate them on VFP.
>3. 99% of the ADSI examples from MS (and their WROX cronies etc) are in VB/script. Oh, did I mention that? :) Well, we also use VB at my company and I have to throw them a bone, I can't say "VFP everywhere" and get taken seriously. I have things locked up concerning data manip and access, but elsewhere I can't push VFP. In this seriously-tiered setup my company is working on, the data access tier is actually seperate from the access and entitlement tier. We were going with something hand-rolled for security/entitlement, but with the new MS Commerce Server stuff, there are pre-built things already made, and they are callable from VBScript (WSH or ASP). So no place for VFP in there other than "forcing" it.

All makes sense. I was just wondering if there was something you found you could only do in VB.

>
>As an aside, I was told by a little bird that MS is making some things rely on C#, or "forcing" you to use C# in some cases (by only providing examples in that language). So you really have to spread yourself out....

I don't see how they can do that, as C# uses the CLR.