On each client the vfp9 exe has to run 24x7 ? How many clients ? What load on the client ? Load balancing achieved how ?
I cannot get a clear picture of the problem areas, but you might consider running 2 instances of the vfp9 exe on each client with an easy interface to start/stop from outside (for troubleshooting or new versions) on todays machines. When including too much "foreign stuff" and if no need for bloody gigantic marshalling exisits I tend to use out-of-process exes, even in chains. That way you get redundancy in the vfp9 exe as well by having a tiny stub so short no problems should happen there. vfp has a few shortcomings, but locking up the OS is not among them - easy to kill most of the times. So each exe looks if it is time for a suicide, checks the other instance is alive and electronic seppuko afterwards.


>Still the option may be better because the VFP exe has to run 24x7 with no downtime. It is a mission critical app that never gets shutdown.
>
>>Then my scenario would put the API dll into their own Dotnet Exe, communicating with the Server Exe from each client. Vfp Exe calls other Dotnet Process and can kill the Exe wholesale. Dotnet Runtime should be free from vfp process space. But restarting Dotnet might not be THAT much faster than vfp plus dotnet <g>.
>>
>>>>I am not sure I follow.
>>>>There is an (C#)-Exe on the server. C#-Dll's communicate on a couple of clients with that server. Each C#-Dll is called via COM locally from a vfp9 exe ?