See Download File#14218 - VFP MTDLL Project Hook. The whole Unload can be automated in a VFP Project hook which is handy when you recompile. This works great when the VFP mtdll is called from ASP - everything is transparent. This is assuming the VFP mtdll is running in Pooled Isolation or High Isolation, not Low Isolation(which is dangerous anyway). You can do this manually by just pressing the Unload button for that application in the IIS management console.
All of the settings(Error, Session, Locks, etc.) in ActiveVFP (www.activevfp.com) are well tested since about 2001 and I like to think of it as a compilation of "Best Practices" for VFP mtdlls. All of it is free too so no need to worry about that...
>I don't use comreturnerror. All my com code is wrapped in try catch constructs so no error is ever thrown without being caught, handled and logged. Everything is done in private datasessions and all tables, databases and instances of the classes are closed between posts. I wouldn't know how to go about unloading the DLL so it could be replaced without restarting IIS after a recompile.
>
>
>>I'm not convinced that the VFP mtdll can't be "Unloaded" after being used by ASP.NET, but, I haven't seen a solution yet. A good place to check would be sites that have VB mtdlls and are trying to do similar things with ASP.NET. Personally, I have never had a problem requiring a restart in this environment (not including recompiles) - make sure you're using COMRETURNERROR and the VFP Session Class. As far as DLL hell, I don't think MS ever touted .NET Interop with COM as a solution to this, just the pure .NET environment. You still have to register the vfp mtdll on the web server (this doesn't qualify it as hell, though -imo-)...