Rick,
As I've said before, you can easily unload .VFP. mtdlls called by ASP either by pressing the Unload button in IIS MMC or automate the unload in a .VFP. project hook. This assumes it's running in Pooled or High Isolation mode. I'm not convinced you can't manage the server remotely either (I'll be trying this in AVFP 2.5).
Any .VFP. mtdll web application I've ever created has recovered immediately and gracefully from every error that's occured - mostly I think because of placing COMRETURNERROR in the error method.
I don't understand what you mean when you say it can't "Keep State". I keep state in .VFP. mtdlls all the time with either the ASP session object or a custom SessionTable object.
I never worry about closing tables. If it is actually opening and closing .VFP. tables automatically my web applications are completely unaware of it and it must be blazingly fast.
I think the dllhost.exe is similar to what you're talking about with .EXE servers - all pooled or high isolation .VFP. mtdlls are run from that as I understand it...

>> (extra COM references which basically locks it into memory - this is why you can't unload a VFP COM server after having been loaded into ASP/ASP.Net).
>
>* Manage the server remotely (start, stop, hold, update etc)
>* Recover from failures
>* Keep state
>
>All of these are related to the fact that EXE servers are external to the calling process and can be monitored and managed through the ISAPI interface (or through an external watcher application). DLL servers are hosted inside an uncontrolled aplication (IIS).
>
>In fact if you look at the architecture of ASP.Net you'll see that it uses Out of Process components (not with COM, but named pipes in this case) that to do exactly that - an external process that can be managed is controlled by a small ISAPI extension. This is smart design as it amkes it posssible to put metrics and maintenance smarts into the server so it can fix itself on failures and allow things like automatic updates without shutting the Web server down. Heck, that's the way Unix has been doing server design since the eaerliest times of server applications (daemons).
>
>All that said, MTDLLs work well, and they are very fast in loading etc. and they've gotten faster yet with IIS 6. But the load speed is also diminished by the fact that you have to re-establish your complete environment on every hit, you can't leave tables open or connections established which overall causes more slowness than any COM overhead might. If you have an application with large VFP tables or tables that sit on the network your performance will be crippled by the requirement to re-open tables on every hit.
>
>OTOH, these days performance is not nearly as much as an issue as it used to be. Today the hardware is so fast that all but the biggest applications cause a server to not be able to handle traffic on a single box. The big exception to these things are CPU heavy applications and in those VFP in general is a problem, and the overhead of calling a MTDLL or EXE component is not an issue in the first place.