Click Event Context

Add-in Express™ Support Service
That's what is more important than anything else

Click Event Context
 
Matt Driver


Matt


Posts: 152
Joined: 2004-08-17
I think what they are saying is do not release any Outlook references which you have not created which could have another application or process hooked to them. if you have created a reference yourself to an outlook object you should definately release it otherwise when the add-in shuts down it will be left orphaned and Outlook will never close. The add-in is not going to release any objects you have defined as it does not know anything about them its up to you. I have 200+ users with Outlook add-ins running and before my MS guru explained that I should be releasing my own references I had outlook hanging and never closing on these clients as soon as I do:

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

Outlook started behaving properly.

If I am now wrong wether you are using VSTO or .NET ADX makes not difference if you create a reference its up to you to release. I believe ADe in that article means you should never release any refences passed to you by VSTO.

Matt
Posted 22 Sep, 2006 08:22:19 Top
Sergey Grischenko


Add-in Express team


Posts: 7235
Joined: 2004-07-05
Hi Rick.

I agree with Matt.
Thank you, Matt.
Posted 22 Sep, 2006 08:49:44 Top
Rick Koch




Posts: 172
Joined: 2006-09-05
I think the real question is whether we should be using ReleaseComObject or instantiating IDisposable classes with "using..." statements and setting variables to null when no longer needed.

No matter how much I read about Marshal.ReleaseComObject, Microsoft sources *always* describe it as the very last way you want to release resources.
Posted 22 Sep, 2006 12:05:39 Top
Matt Driver


Matt


Posts: 152
Joined: 2004-08-17
I personally use the:

Try
{}
catch
{}
Finally
{}

process. Any objects I create in the function I then release in the finally that way if you get exceptions they are still released cleanly.

Mattt
Posted 22 Sep, 2006 16:01:27 Top
Matt Driver


Matt


Posts: 152
Joined: 2004-08-17
Oh one thing to add that my Micosoft Guru explained to me I think is:

Outlook or .NET (not quite sure) keeps a count of COM objects allocated from itself so everytime you create a variable and allocated it to a COM object in increments a count of allocations. Now if you release your objects cleanly when Outlook comes to close the allocation number will be zero so it thinks their are no external handles and will close cleanly.

But if you don't deallocate something then when outlook closes it will see that an unknown object still has a handle to its process and it will not close. You cannot just leave outlook to clean up and it does not have a handle to any of these open references it will just wait for ever (maybe or just sometimes knowing Outlooks odities)

So you should definately release all objects once you have finished with them.

In reference to the ADX Outlook knows nothing about the references it has created (by your code) so when the add-in closes it will clean its references but but if you have not deallocated your own code references it will have open handles and will not close correctly.


Hope this makes sence

Matt
Posted 22 Sep, 2006 16:07:58 Top
Andrei Smolin


Add-in Express team


Posts: 18224
Joined: 2006-05-11
Rick,

See my article Why Outlook isn't closing
Posted 23 Sep, 2006 04:54:27 Top