OpenSharedItem and .MSG files

[SeekerOfTruths]

Hi, I'm having a little difficulty with OpenSharedItem in the Outlook 2007
add-in that I'm writing.

The purpose of the add-in is to detect when the user opens (double-clicks)
certain items and to retrieve an alternative item which has been stored
elsewhere (i.e. not in Exchange) and present this item in an inspector window
instead of the original item.

I can hook into the Open event no problem, and when this event fires I
perform a check on the item being opened to see if it needs special
treatment. If it does I acquire the alternative item to be opened (as a file
on disk), use OpenSharedItem to give me back a object referencing the item on
disk, create a new inspector window using this new item and then cancel the
open event on the original item.

This all seems to work fine, except for the fact that when I close the
inspector window containing the alternative item, a handle to the file on
disk remains open which prevents the file on disk from being deleted. This
would suggest that there is still an object somewhere that is referencing the
item on disk, but I''m not sure where the reference is or how to go about
tracking it down (I've set all the instances that I'm aware of to null in my
code).

If anyone could give me suggestions on what might be wrong and/or how to
track down the problem, I'd be very grateful.


Thanks,

SeekerOfTruths

 

[Ken Slovak - [MVP - Outlook]]

..NET code or what? If this is .NET code are you releasing the object
reference you got from OpenSharedItem() possibly even by calling
Marshal.ReleaseComObject() on it and then calling
GC.WaitForPendingFinalizers()?

 

[SeekerOfTruths]

Sorry, I should have said what it was written in to begin with - yes, it's
..Net (C#) code. Unfortunately .Net and C# are kind of new tech to me (I'm
more of a C++ Extended MAPI store provider kind of person) so I'm just sort
of writing the code and picking things up as I go along (very bad practice I
know, but needs must when the devil drives).

I did try throwing in a ReleaseComObject call to see if it had any effect
but didn't notice any change in behaviour, but then I hadn't included any
garbage collection calls.

 

[Ken Slovak - [MVP - Outlook]]

Let's say I have an object oMail. When finished with it I'd use code like
this, assuming that I have no need for any other references to that object
in any context at all:

if (oMail != null)
{
Marshal.ReleaseComObject(oMail);
oMail = null;
}

GC.Collect();
GC.WaitForPendingFinalizers();

That call to ReleaseComObject releases the RCW for that oMail object.

The down side to that is if you have live references to the underlying mail
item represented by oMail anywhere else in your program.

Those will become invalid when the RCW is released since the Interop only
creates 1 RCW no matter how many object references to the object you
instantiate in different scopes.

So when passing a reference to oMail by value to a procedure if the
procedure releases the RCW the passed reference will be invalid in the
calling procedure.