Outlook COM Add-in and Outlook Automation at the same time?

[Michael]

I am writing an Outlook XP/2003 COM Add-in in C# (Visual Studio .NET 2003).

My add-in loads with Outlook and runs successfully. However, I also have a
separate C# application which creates an Outlook Application instance (e.g.
Outlook.Application olApp = new Outlook.ApplicationClass() and passes that
to some of the methods in my add-in dll to read data in the Outlook Object
Model (in the add-in I get the application object in the OnConnection
method). For instance, the program might look in a specific folder for
tasks and read some built-in and custom fields. The application only reads
information; it does not change/write anything.

If I run Outlook without the application running, it works fine. If I run
the application without Outlook running, it also works fine... it creates
the Outlook.exe process (which takes many many seconds to initialize while
it does an initial Send/Receive, etc.) while it is accessing the object
model and the process goes away about 5-10 seconds after the application
exits.

However, when I try to run them together, I'm experiencing strange problems
which I am still investigating. The problems seem to be different,
depending on which app I start first, some of which stems from it loading at
times with an Explorer (Outlook) and other times without an Explorer (C#
application). NOTE: The add-in is not currently loaded using a Shim, though
I plan on doing that soon (if that makes any difference).

Without getting into too many details of the problems in this post, which is
already long, I was wondering if this scenario is even acceptable, and if
not, how might I approach it differently?

Michael

 

[Ken Slovak - [MVP - Outlook]]

If you start Outlook without an Explorer and allow your addin to instantiate
you're going to have problems because it won't know to release Outlook
objects when the user closes Outlook if an Explorer is added later. You need
to trap Explorer.Close to know when to release your objects.

The Application object passed in On_Connection is trusted (at least in some
versions of Outlook) and you derive all objects from that to make them
trusted. Passing in an untrusted Application object will make all objects
derived from that untrusted. So you will be subject to the security
restrictions in Outlook 2003.

You might want to look at passing in EntryID's for folders and items with or
without StoreID's instead. That will isolate any trusted and untrusted
Outlook objects.

With .NET code make sure to explicitly release your objects and then call
the garbage collector to release all references so Outlook can close
gracefully and not hang around in memory.

 

[Michael]

Ken,

Thanks for the info. I now understand the issue of not knowing when to
dispose of objects. I do take great care to dispose of my COM objects
properly, but as you indicated, I won't always know when to actually do
that.

I didn't realize until recently that my Outlook Add-in and my C# program
using Outlook automation would actually execute in the same Outlook.exe
process, since only one Outlook.exe runs per machine. This is certainly a
problem for me, as my design has not accounted for this.

Michael

If you start Outlook without an Explorer and allow your addin to instantiate
you're going to have problems because it won't know to release Outlook
objects when the user closes Outlook if an Explorer is added later. You need
to trap Explorer.Close to know when to release your objects.

The Application object passed in On_Connection is trusted (at least in some
versions of Outlook) and you derive all objects from that to make them
trusted. Passing in an untrusted Application object will make all objects
derived from that untrusted. So you will be subject to the security
restrictions in Outlook 2003.

You might want to look at passing in EntryID's for folders and items with or
without StoreID's instead. That will isolate any trusted and untrusted
Outlook objects.

With .NET code make sure to explicitly release your objects and then call
the garbage collector to release all references so Outlook can close
gracefully and not hang around in memory.

 

[Ken Slovak - [MVP - Outlook]]

Yes, only one instance of Outlook will run at a time and the COM addin will
be running in-process with Outlook itself.

You really should not only set objects to nothing (or however you release
them in C#) but also explicitly call a Marshall.ReleaseCOM call (or whatever
the syntax is) so the objects are released by the garbage collector at that
time rather than whenever it feels like it.