And Rick, I do not mean this sacastically in any way
if your answer is "no". Does your web product get
around this problem? I ask this because on high
traffic web sites, this has been an absolute
problem with ASP\VB Com. Reinstalling the hourly dll
has become a politcal no-no (programmers vs marketing people).

Eventhough I am a programmer, I agree with the
marketing people. Re-installing is not customer-friendly.
They (marketing) wants feature after feature ever
hour after a customer calls. But they don't want us
to reinstall the dll with the new feature because the
customer gets offended.

And then there are WHS (web hosting services) that say
you can only reinstall a DLL (non-MTS, reboot) every
two to three days. In other words, it takes two to
three days to get your dll into production.

COM objects (without MTS) is a diaster. COM objects
with MTS is a workaround, not a solution. Does West
Wind get around this diaster?


>woweee...
>
>There's some really bad information in this thread.
>
>#1
>The reason you can't kill a DLL is because IIS loads COM objects that are
>loaded through this process. Since ASP does this there's an extra LoadLib
>performed and thus DLLs can't be unloaded directly.
>
>#2
>The easiest way to kill IIS is to use the NT Resource Kit KILL.EXE
>utility and then do:
>
>KILL INETINFO
>pause (wait for about 5 seconds)
>NET START IISADMIN
>NET START W3SVC
>
>This kills the service dead immediately, then restarts it with the
>service manager.
>
>#3
>You can use 'virtual applications' in which case the IIS virtual
>directory runs as a private application inside of MTS. In this
>the entire IIS 'application' including any COM components you create
>in it run inside of that MTS package.
>
>You can Unload this package from the IIS management console, which
>releases the IIS app as well as your COM components. This process
>is relatively fast, but very unreliable in a site that's actually
>online as any hit against the virtual will immediately restart the
>'application'.
>
>
>The only reliable method is #2. If you do this right via a batch
>file (that you might even call from VFP) it's also the fastest.
>
>
>
>For more information on this stuff along with other VFP COM
>development issues check out:
>
>http://www.west-wind.com/articles.asp
>
>
>
>
>
>
>
>
>Hi:
>>
>>I need to kill a VFP 5.0/6.0 DLL loaded in NT memory. There it is any utility o trick.
>>
>>You cannot rebuild the DLL becasuse there is another in memory.
>>
>>TIA
>>
>>Alberto Rodriguez
>>Spain