Interesting 'analysis' and I resent having technology, that has proven itself in a huge number of real world apps, called a 'hack'.

There's nothing wrong with EXE servers in IIS - it's no less of a 'hack' than using COM DLLs which ultimately use exactly the same model. COM and IIS in any combination is not exactly stable technology. These days in light of Microsoft's shift away from COM to .Net you hear this even from Microsoft.

Both use STA model components to access a COM object. That's the whole point of COM remember??? It doesn't matter whether you access a DLL or an EXE. The difference with an EXE is that it's a proxied object always, where a DLL may or may not be proxied (in IIS it mostly is proxied because of thread issues).

The reason I long have used EXEs (in Web Connection) is because you can do something that you can never do with a DLL in ASP: Manage it! With an EXE you can control the lifetime of the server and more importantly you can detect a failure and reload it, which you cannot do with a DLL in IIS. If you ever crash a DLL it will require an application restart to get it to run again.

You can also control load to limit the amount of instances that are active so you don't overload hte system with long slow running requests (like crunching a report).

Yeah for trivial applications none of this may matter much, but for production applications that need to be updated in real time, and need to be remotely administered to do things like maintain FoxPro tables (with SET EXCLUSIVE for example) management is unescapable and impossible to do with DLLs and the ASP/COM model.

FWIW, Web Connection has for years included a DLL base class module that allows a WWWC application to run as an ASP/COM component. Nobody uses it although a number of people have played with it and even after requesting it those folks went back to using hte EXE model. Reason: You have to give up too much to play that way...

So while it may be that ASP/COM is what comes out of the box that doesn't mean that using something different is automatically dated or no longer a valid technology. I think the number of people using (and having paid for) and continuing to use this 'hack' technology more than bears out that premise.


+++ Rick ---


>ActiveVFP is using the ASP and ASP.NET isapi dlls and inheriting objects from them, so, it's still ISAPI and still just as fast if not faster than FOXISAPI. The key difference is the backend vfp servers - whether an .EXE COM server or the more modern multi-threaded VFP .DLL COM Server. FOXISAPI and some of the other 3rd parties are using multiple running .EXE COM servers, which always has been sort of a hack, while VFP Web Services and ActiveVFP use Multi-threaded VFP dlls which is the best environment for using VFP on the web...
>
>>I think so I couldn't understood somethings. Than your Activevfp don't use foxisapi?