We developed an application that uses Excel interop libraries (Microsoft.Office.Interop.Excel) to read some Excel files.
When a problem occur in the application, the event Application.ThreadException is handled, so the resources are released (Excel is closed...).
The problem is that when we use the VS debugger, if we stop the execution (because the process breaks on an exception, or a breakpoint, there are lots of reasons why we'd do that), the resources are not released and Excel stays opened.
And of course, next time the application is launched... it crashes because there are locks on the file.
So I'm looking for a way to force the release of the Excel objects, even when stopped with the debugger.
Any suggestion ?
You can use the DTE (VisualStudio Automation Model) to write a macro that will be invoked when a stop debug happens, below is a snippet of the idea.
Private Sub DebuggerEvents_OnEnterBreakMode(
ByVal Reason As EnvDTE.dbgEventReason,
ByRef ExecutionAction As EnvDTE.dbgExecutionAction) Handles DebuggerEvents.OnEnterBreakMode
If (Reason = dbgEventReason.dbgEventReasonStopDebugging) Then
// DO YOUR CLEAN UP CODE HERE
End If
End Sub
One possibility is to switch to a pure .NET solution such as SpreadsheetGear for .NET to get away from the performance and reliability problems associated with COM interop.
Disclaimer: I own SpreadsheetGear LLC
Unfortunately there isn't a way to do this. The stop button in visual studio kills the process, so it doesn't have any chance to clean up.
As a possible way round your problem (although not a very good one), you could write a cleanup routine and execute it manually from the immediate window before stopping the app.
[Edit: Ignore me. This answer is wrong. Shay Erlichmen has come up with a much better solution using a macro]