>Nick,
>
>>If you are planning to use your COM on the remote server then there is no question - it has to be compiled as an EXE.<
>
>I'm probably showing my ignorance about this subject, but why would it have to be an .exe on the remote server? Why couldn't you not have a .dll together with the VFP runtime files?
>
A VFP .DLL doesn't have a WinMain, or the ability to create itself as a process; it relies on a host environment for this, running in the context of the process that starts it - hence in-process. An out-of-process server runs as a separate, distinct process from the client that uses it; it can have its own WinMain, and can be used as a separate process, rather than a thread in the context of the client.

You need a process to host the in-process server; it isn't capable of running by itself. You could use a service such as MTS to host instances of the in-process server; the in-process server then runs in the context of the MTS process on the remote server; clients talk to the MTS process, which then manages instances of in-process COM objects that it runs in it's process memory as a thread, handling the application environment issues like security contexts, process management and object management, marshalling messages between clients and server instances, etc. IOW, your remote app is really talking to MTS to call the in-process DLL, and MTS then runs instances of in-process servers inside itself on behalf of remote clients.