Rick,
Sorry, if I have an opinion I'm going to give it and not according to your terms. If you remember, this thread was about foxisapi. You're the one that jumped in and felt you had to defend your own technology.
While you have done some very good work, I feel that you tout your own technology at the expense of moving forward with what's coming out of Microsoft. Could it be that this is because you're afraid developers won't need and therefore won't purchase your products?
BTW, as you know, vfp mtdlls also work with ASP.NET. It's only through the active discussion of web development in this environment that problems can be found out and solved. Scaring people away from developing in this environment does the community no good as I would think everyone agrees that we would like to see vfp continued to be used in the future and with the latest technologies...

>An exe IS Safer. By definition. Because it is NOT running inside of IIS a crash in your server is never going to take down IIS. And as mentioned previously you can manage it remotely.
>
>My point is that EXE servers are just as viable as MTDLLs and for my needs (and those of my customers who have asked for the features in the first place) it is and has always been an improvement over the ASP model.
>
>If you go by pure arguments of why MS implemented this or that you're in trouble because ASP + COM is now considered legacy technology. ASP (as well as the ISAPI COM interface) + COM is just not all that well suited to a multi-threaded environment and has always been more or less of a house of cards which is by your definition would be a 'hack'. To enforce multi-threading onto a non-multithreaded environment (VFP, VB) is necessarily a hack.
>
>That doesn't mean it doesn't work, but it does mean that the system has to do a lot of work to make it happen and most of that overhead is there regardless which mechanism you use.
>
>I'm getting tired of your implicit references. If you have a problem or something concrete go ahead and spit it out and we can have a discussion about it, instead of the indirect propagandatizing you engage in.
>
>
>+++ Rick ---
>
>>Rick,
>>This is a good defense of .Exe servers. The problem I see though is that many developers are have gotten the mistaken impression that having .Exe servers or even single threaded dll servers is "safer" for some reason which is not true. vfp mtdlls can easily be stopped and started without affecting IIS or other applications. Also, they just seem to work smoother. You never have to worry about starting them in the background or hacking up SRVANY to have them start automatically when startup occurs. All of this happens automatically with mtdlls. Add to this the horror that is DCOM configuration of .EXE servers and it adds up to a lot of time with manual configuration that may or may not work. Also trying to explain to clients that their web environment has 3 .EXE vfp servers servicing thousands of web users and it just doesn't sound right, deservedly so. I have seen many, many large scale VFP web apps built with this configuration crawling and I see VFP mtdlls as an improvement
>to
>> this situation. It can only help to have a lot of vfp developers using this technology and developing it more instead of being scared off for the wrong reasons...
>>BTW, nobody uses your mtdll version of wwc because it is actively UNsupported by you with little documentation. I have seen users ask about it on your support board and been told just not to do it that way. Also, why did MS choose vfp mtdlls and not .EXEs as the basis for vfp web services and make it the standard for VFP web development??
>>>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?