GT,
I am one of the developers that worked on this problem for VSTO. Unfortunately, your scenario has a few details that make it unrelated to the one we faced in VSTO.
In your scenario, you are actually debugging your winform application, not office. When you hit Stop in the debugger, your application is terminated forcefully by the IDE (think Win32 TerminateProcess). No finalizers run, no dispose methods are called, the process just ceases to be. This is where your problem lies. You are automating office externally which means your application is actually talking to COM Interop RCWs (runtime callable wrappers). The RCWs are holding references to objects in Office's automation object model across process (via IUnknown.AddRef). The externally automated app does not shutdown unless the ref-count for these objects drops to zero, or the it is terminated. The finalizer for an RCW releases its reference to the com object via a call to IUnknown.Release. However, like I explained above, hitting stop in the debugger does not execute finalizers. Therefore the reference is leaked and office will continue running. If, however, you close your application gracefully (via the exit button or some other means) finalizers will run in most scenarios and office should shut down cleanly.
In VSTO, the addins run inside of the Office process (i.e. word or excel). The debugger is attached directly to that process, not an external application like in your scenario. When the user hits stop, the debugger attempts to make the application shutdown cleanly. Failing that, it forcefully terminates the process. So, in VSTO, the lifetime of the process is not directly linked to the ref-counts of the object when debugging ends.
Hope that helps clear it up a little.
Jackson Davis - [MSFT]
This post is provided AS-IS and confers no rights. |