WPF Applications in VSTO not being garbage collected

Question

So, I'm building applications for Office (via VSTO's) with C# and WPF. I'm seeing that the WPF application (via memory profilers) is never collected after being launched.

I'm going as far as creating a new AppDomain for the WPF Application, launching it inside that AppDomain, and following the use, Unloading the AppDomain, but I still have objects around -- and my handles are still increasing in size.

Does anyone know of any strange behaviors of VSTO and WPF applications? My only guess is that for some reason, the WPF application is loaded on the UI thread shared by Office, so it never gets cleaned up...

Any thoughts on the increasing handles? I'm getting a lot of backlash from my client's deployment team that the "increasing handles are not acceptable."

EDIT:

Let me be clear -- the WPF applications are launched from the Ribbon, and they then produce output in the respective application, i.e. if in Excel, you'll enter information and it will then build a spreadsheet for you based on the information provided; if in PowerPoint, you'll enter information (in the WPF application launched from the ribbon) and it'll build a slide based on the information you provided.

score 1 · Answer 1 · edited May 23 '17 at 12:14

My understanding is that VSTO solutions (at least as of Visual Studio 2010) always use a default COM shim to load the VSTO add-in to a separate AppDomain. This isolation protects your add-in from any instability of other add-ins.

Perhaps your application's memory usage is growing in due to hidden runtime callable wrappers (RCWs) created when interacting with the VSTO host application (e.g., Excel)?

My first VSTO app initially relied on Marshal.ReleaseComObject() to free RCWs, however, I changed my approach to use below based on these blog articles:

I now use this approach to force the GC to

public static class OfficeHelper
{
  /// <summary>
  ///   Forces a GC to release unused run time callable wrappers around COM objects
  /// </summary>
  /// <example>
  ///   dynamic rcw;
  ///   try
  ///   {
  ///      rcw = Globals.ThisWorkbook.ActiveSheet;
  ///      // do something
  ///      // ...
  ///    }
  ///    finally
  ///    {
  ///      rcw = null;
  ///      OfficeHelper.Cleanup();
  ///    }
  /// </example>
  public static void Cleanup()
  {
    System.Diagnostics.Debug.Print("OfficeHelper::Cleanup - GC forced");
    GC.Collect();
    GC.WaitForPendingFinalizers();
    System.Diagnostics.Debug.Print("OfficeHelper::Cleanup - GC finished");
  }

}

So far this approach has worked well in my app, and the GC times have been faster than I expected.

I actually have those two lines after every application "ends"... but I still see an increase in handles/memory/etc. The memory isn't a big issue, but the handles seem to be. — Locke, Feb 25 '14 at 16:00
From [Ji Zhou of Microsoft](http://social.msdn.microsoft.com/Forums/vstudio/en-US/086b7b17-f4d2-4f84-aeb3-68e9ffdbf9a8/what-are-the-similarities-and-differences-between-shared-addin-and-vsto-applicationlevel-addin?forum=vsto): > Visual Studio Tools for Office creates a new AppDomain to load each of the VSTO Add-Ins. So, it will not affect each other. Programmers do not need to worry about the "Outlook won't shut down" issue. When the VSTO Add-in shuts down, the AppDomain gets unloaded and it will recycle the resources the programmer has allocated in the application. — Steve Jansen, Feb 26 '14 at 01:11
What if we launch apps from a VSTO ribbon, which create a slide/output? i.e. You click a button on a VSTO ribbon and then it launches an application that takes some information and automates building a slide with the interop types? — Locke, Feb 26 '14 at 15:29

WPF Applications in VSTO not being garbage collected

1 Answers1