Thanks for the speedy reply!!

I was afraid of that. I don't want to kill IIS because other developers use the server for testing as well. Guess it appears that the trick of just creating a new one each time is the best from a development cycle standpoint. Even after killing IIS there is a delay of several seconds, perhaps even a minute before the COM can be overwritten.


>Since the COM object is not running in VFP's memory, it would be difficult, if not impossible, to shut down the component. You can run the component as a COM+ application, then just shutdown the application. If running under IIS, you can shutdown IIS, or that component (depending on the version of IIS that you're using)
>
>>I've re-written some ASP routines into VFP COM objects. Good news is performance is at least 8-10X better. Bad news is that the development cycle of compiling and testing the COM objects is insane.
>>
>>Right now I basically rotate about 20 projects all with the same PRG containing the COM object class. After making changes to the code I build the COM object then go into the ASP code and change the CREATEOBJECT call to the new COM. At that point when I go to the page to test it, the web server locks up that COM object so the next time I build I use a new project (same code) to create a new COM. That way I don't have to take down the server and wait for the COM to get released from memory so I can rebuild. I don't like however registering 20 COM objects almost all the same just so I can keep working.
>>
>>If there is ONE thing I would have liked to have seen in VFP 9 would be that building a COM object that is already in use would prompt and say "Remove COM from memory?", you click YES and that's it! But I'm assuming that is not an option.
>>
>>Any ideas on how to best handle the COM object development cycle? Any ideas on how to hook into VFP build process to automate removing the COM from memory? Seems like that could be a pretty darn useful app!!
>>
>>Thanks in advance!!!