For typical web apps, you probably don't want a client application unloading your vfp server app(although I don't think it would be that hard to actually program this - see next statement). VFP mtdlls typically run in Pooled or High Isolation applications which can easily be 'unloaded' from IIS without affecting other applications or IIS(just push the 'Unload' button). This also can easily be automated as I did with the VFP project hook in the downloads section.
My theory is that you don't emphasize mtdlls with WWC because you've invested so much time and effort into your isapi extension and this is your proprietary code - emphasizing mtdlls could possibly make your commercial product less necessary because they work so well with ASP.NET/ASP. That's my only explanation since vfp mtdlls are an obvious improvement to all web development that's gone before in vfp.
Thanks for that blog. I'll try to respond to it in more detail directly on your site, but, here are some first impressions:
Myth 1)There's an issue with debugging mtdlls -Wrong! Debugging in ActiveVFP has improved with each version. Version 2 and 3 allow debugging of COM servers. Version 3 works with Win 2k, xp, and windows 2003. No issues at all, no recompiling necessary, just like regular vfp. A major problem with WWC is that many, many developers are using what amount's to "debugging" mode(file based messaging)for production servers. The switch to COM based processing in WWC has been characterized as a "b*tch" because it so hard to set up and get running, so, many just don't do it. AVFP, on the other hand is always high performance COM messaging.
Myth 2)There's an issue with mtdlls and the stability of the server Wrong! Mtdlls typically run in Pooled or High Isolation. This and the use of COMRETURNERROR allow graceful error handling and no major crashes. Also, with version 3 of AVFP you can simply swap out the main.fxp without the need to unload the application or web server(with vers. 2 you'd just 'unload' the app).
Myth 3)Performance/scalability is somehow better using pooled EXEs - Although the performance/scalability numbers are about even in the perf numbers you got, I don't think you mentioned some of the details like # of wwc servers running and the corresponding memory requirements. For each of those EXE servers the regular vfp runtime is loaded as well. Not true with mtdlls - one runtime is loaded and it's the smaller optimized one. Also, I believe your wwc apps are running in low isolation - did you also run the mtdlls in low isolation too?
