GC Problem - Finalizing

Arch4ngel

Arch4ngel

Well-known member
Joined
Mar 22, 2004
Messages
940
Location
Montreal, QC
I got a big problem that I would like to solve.
I have an operation that MUST be executed right before the Finalize() instruction.
What I wanted to do... is to override it and put my instruction and do a base.Finalize() right after. However... VS.NET 2003 Professional (only my version) doesnt allow this kind of operation.

Ive already implemented the IDisposable interface so I might use Dispose().

Heres what I want to know :
  • Does Dispose() is called by the GC ?
  • If not... is there a way of doing what I want to know without trying to override the Finalize instruction ?
 
You can overload the finalize method its just that C# forces you to use the C++ destructor syntax.

C#: 
class class1{

class1()
{
//constructor code goes here
}

~class1()
{
//this is the finalize method
}
}

Dispose is not called by the garbage collector though. If you have already implemented a dispose method you should really do most of your clean up there.
One possibility is get the Dispose method to call your finalize method internally and then have it execute a GC.SupressFinalize(this) to prevent the GC calling the finalize a second time.

You may find this link useful.

Just out of interest what does the class do? Unless you are dealing with unmanaged / expensive resources you may not need to worry about freeing up the memory yourself.
 
Im deeling with Interop. Excel ... Im making a class that does a lot of it and I dont want to have some loner Excel instance that is still running in the background.

Its the only way I found to make sur that all the ressources are freed upon termination of the program.

This class is supposed to run on ASP.NET on a big server that run alot of other intranet web site. So I dont want to overload the machine and want to make sure there isnt gonna be memory leak ( loner instance of excel that cant be closed because it was opened by aspnet account).
 
I got it to work.

I dropped a breakpoint inside the destructor and its going in.
So Ive to make sure that everything got destroyed correctly. After that... I wouldnt have to bother about freeing all things :)
 
I think you fret needlessly - the CLR maintains the reference count on the COM object just as any other COM client and releases the object when the count goes to 0 (not
during GC) so you can treat the object as if it were GCed, but the GC isnt really involved.
 
Yeah... maybe...
But why after 3 day of work (without stopping my computer) those Excel program didnt got away ?
Why did they still use 3Mo of RAM each ?
Why when I do a GC.Collect() they dont go away ?

The solution of this... is its still open and need to be closed properly. That means to Release the COM object. And thats why I do it in the Finalize of my program.

Understand dude ?
 
Back
Top