VSTO References to COM Objects / Memory Usage

My questions is regarding VSTO .NET development with Outlook.

Due to the way .NET event handlers are handled in VSTO, it is necessary to hold a reference to the COM object representing the item for the event handler on the item to be fired. This is done by declaring a class level variable that will keep the reference from being garbage collected.

My addin is handling the BeforeDelete event for the Calender, Contacts, and Tasks.

I am worried that keeping List's of references to all individual items is going to use a lot of Memory for users with large collections of Appointment items, Contacts, and Tasks.

My questions is about the underlying COM object I am keeping a reference to. Does this object hold all of the item's details, or is it just a pointer that Outlook uses to load the details from the datastore. For example, when I ac开发者_运维知识库cess the FirstName property of a Contact item, is this loaded directly from memory or is is loaded from Outlooks PST file.

I don't recommend holding references to every calendar item, task and contact. This will cause the majority of RCW's to make it to gen 1 or gen 2, meaning they are not likely to ever get cleaned up by a garbage collection. The objects themselves never move into the .net space, but you will get a RCW for each one, which stops the memory from being cleaned up on the unmanaged side. This also can cause issues in Outlook where calendar items get locked and you can't resize them, and other random issues...

I would recommend instead using my FolderMonitor class out of my VSTO Contrib project (http://vstocontrib.codeplex.com/SourceControl/changeset/view/50a83624e34d#src%2fVSTOContrib.Outlook%2fOutlookFolderMonitor.cs) which will raise a deleted event when an item is being deleted, that way you will only have a reference to 3 RCW's (Contact Folder, Tasks Folder and Calendar folder).

This is almost certainly loaded from memory. But the pressure you put on Outlook happens when you create the COM object, then Outlook has to do whatever it needs to do to obtain the object data. Which it probably keeps around until you stop referencing the object and the finalizer thread runs. But sure, if you reference everything then you'll likely give Outlook a hard time. Excessive memory and pagefile usage are symptoms of trouble.

This is just a guess, the internals of Outlook are not documented. I do recommend you try to create a realistic load and have a look-see with a tool like SysInternals' Process Explorer.

You may be working at cross purposes here

This is from the Help of the BEFOREDELETED event

In order for this event to fire when an e-mail message, distribution list, journal entry, task, contact, or post are deleted through an action, an inspector must be open.

That "An inspector must be open" phrase is the key. You won't ever be able to open an inspector for each email, contact and calendar item. The BeforeDeleted event is only applicable to those items that the user has actually opened in Outlook.

What you probably want to do instead is to obtain a reference to a specific FOLDER object and monitor the events on that folder (I believe it's BEFOREITEMMOVE, which is weird but deleting an item is basically moving it to trash).

It's been awhile since i've looked at outlook so my nomenclature may be a bit off....