I'm not sure that would be possible. I have to think about it. There is an exe running in memory on a server. The api to communicate with that exe is in a dll. I create objects from that dotnet dll from my app. Now, imagine one copy of the exe running and 20 copies of the dll api running... I believe the garbage collection needs to happen in the dll.



>Tracy,
>
>be warned: mostly pure speculation! What would happen if you run a dotnet exe, call COM objects "in there" and have an option to trigger suicide in the dotnet exe ? Should clean the process space.
>
>OTOH you might fool around developing in one session and for testing always firing up a brand new vfp via predefined keyboard strings guiding you halfway "testdriven" like. I used to work more in this "traditional-language" style using tiered apps and not using the command window often - works for some apps quite good, would be lousy at my current tasks.
>If you keep biz code in prg's, works great, if you mostly have vcx in the project, make it a habit to put temporary versions into SSafe more often - under vfp6 vcx trouble happened once a month, under vfp8 and vfp9 much better.
>
>regards
>
>thomas
>
>
>
>>Thanks for the input. Not really a viable option unless it can be resolved. Just can't see users closing VFP in order to get it all to clean up periodically...
>>
>>
>>>This isn't limited to VFP, VB 6 experinces this same problem when working with .NET COM visible classes. I reviewed this issue with Alan Griver at a conference a few years back (before the VB Interop Toolkit stuff came out). In any event, he made a call in to MS while we were sitting there and said that the devs said something about a "hard lock" and that there wasn't much if anything that could be done about it. Never did get or understand the technical details about this... but having tried a number of ways to get it to release the reference without any luck (doesn't matter what the reference count is... 0 doesn't cause the garbage collection to kick in). I don't think this is possible Tracy, but I am more than willing to be proved wrong.
>>>
>>>>I am accessing net (c#) classes via VFP9 successfully. However, garbage cleanup is a mess. I've noticed that setting the object in VFP to null and releasing it does not really release them. If I null and release my objects, I cannot rebuild the dotnet dll until I shut down VFP completely and even then, my machine will be sluggish after instantiating a lot of .net objects via com interop. I know that .net uses the .net garbage collector to release an object so how do I cleanup from VFP? What has to be visible via com interop to VFP in order for me to destroy the .net objects I create in VFP that are accessible to me via com interop? Something has to release the objects and even shutdown the .net runtime from VFP...