GC Problem - Finalizing

[Arch4ngel]

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) doesn't allow this kind of operation.

 

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

 

Here's 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 ?
  

[PlausiblyDamp]

You can overload the finalize method it's just that C# forces you to use the C++ destructor syntax.

 

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.

[Arch4ngel]

I'm deeling with Interop. Excel ... I'm making a class that does a lot of it and I don't want to have some loner Excel instance that is still running in the background.

 

It's 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 don't want to overload the machine and want to make sure there isn't gonna be memory leak ( loner instance of excel that can't be closed because it was opened by aspnet account).

[Arch4ngel]

I got it to work.

 

I dropped a breakpoint inside the destructor and it's going in.

So I've to make sure that everything got destroyed correctly. After that... I wouldn't have to bother about freeing all things :)

[pelikan]

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 GC'ed, but the GC isn't really involved.

[Arch4ngel]

Yeah... maybe...

But why after 3 day of work (without stopping my computer) those Excel program didn't got away ?

Why did they still use 3Mo of RAM each ?

Why when I do a GC.Collect() they don't go away ?

 

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

 

Understand dude ?