I have an Windows Forms application that uses the Excel application to create
a spreadsheet, saves it and then quits the excel application - all
programmatically. The problem is that the Excel.exe process remains running
in the background until the windows forms application is exited. I've tried
the following:

//FIRST TRY:

/**Do Garbage Collection as suggested as best practice at:
* http://msdn2.microsoft.com/en-us/lib...ffice.11).aspx
*/
excelWorkBooks = null;
mainbook = null;
sheet = null;
someRange = null;
/**Quit the application.*/
excelApplication.Quit();
excelApplication = null;
/**Collect Garbage (Twice).*/
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();

//SECOND TRY

private void releaseCOMObject(object COMObject){
try {
if(COMObject != null)

while(System.Runtime.InteropServices.Marshal.Relea seComObject(COMObject)0);
}
finally {
COMObject = null;
}
}

//THIRD TRY:
private void releaseCOMObject(object COMObject){
try {
if(COMObject != null)
System.Runtime.InteropServices.Marshal.ReleaseComO bject(COMObject);
}
finally {
COMObject = null;
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();
}
}

The methods are invoked after the application is done using the COM objects.

How can I close the Excel.exe process?

This is a common problem that I've not seen a clear solution for. Any
examples or web links would be helpful.

Most cases of Excel (or other server) failing to close are due to remaining
references.

You need to make sure that EVERY object referenced goes through your
excelApplication object.
Do not use any unqualified objects, as you will then be creating references
to Excel that you cannot set to nothing.

NickHK

"DeveloperSQL" wrote in message
...
I have an Windows Forms application that uses the Excel application to
create
a spreadsheet, saves it and then quits the excel application - all
programmatically. The problem is that the Excel.exe process remains
running
in the background until the windows forms application is exited. I've
tried
the following:

//FIRST TRY:

/**Do Garbage Collection as suggested as best practice at:
* http://msdn2.microsoft.com/en-us/lib...ffice.11).aspx
*/
excelWorkBooks = null;
mainbook = null;
sheet = null;
someRange = null;
/**Quit the application.*/
excelApplication.Quit();
excelApplication = null;
/**Collect Garbage (Twice).*/
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();

//SECOND TRY

private void releaseCOMObject(object COMObject){
try {
if(COMObject != null)


while(System.Runtime.InteropServices.Marshal.Relea seComObject(COMObject)0);
}
finally {
COMObject = null;
}
}

//THIRD TRY:
private void releaseCOMObject(object COMObject){
try {
if(COMObject != null)
System.Runtime.InteropServices.Marshal.ReleaseComO bject(COMObject);
}
finally {
COMObject = null;
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();
}
}

The methods are invoked after the application is done using the COM
objects.

How can I close the Excel.exe process?

Is there a way to get a debug dump of the active COM objects related to
Excel? I've released all of the COM Objects in my application and Excel.exe
still continues to run.

"NickHK" wrote:

Most cases of Excel (or other server) failing to close are due to remaining
references.

You need to make sure that EVERY object referenced goes through your
excelApplication object.
Do not use any unqualified objects, as you will then be creating references
to Excel that you cannot set to nothing.

NickHK

Is there a tool that can be used to debug/identify lingering references?

"DeveloperSQL" wrote:

Is there a way to get a debug dump of the active COM objects related to
Excel? I've released all of the COM Objects in my application and Excel.exe
still continues to run.

"NickHK" wrote:

Most cases of Excel (or other server) failing to close are due to remaining
references.

You need to make sure that EVERY object referenced goes through your
excelApplication object.
Do not use any unqualified objects, as you will then be creating references
to Excel that you cannot set to nothing.

NickHK