We have a product which is essentially an Outlook addin written in VS2005 and VSTO.

The first thing we do on the "Application_Startup" event is to check the user's validity against our server by calling a dedicated Web Service.

If the user is unauthorized, we simpley "return" from the startup event and that's the end of that.

The problem is that the Addin is still loaded into the memory and for some of our clients which work with terminal servers this is a sore-spot.

Is there a way to unload my outlook addin completely


Ayal Steiner


Re: Visual Studio Tools for Office Unloading the VSTO Appdomain in Outlook

John R. Durant - MSFT


You can remove add-ins programmatically. This is the course of action you should take.

Use: Outlook.Application.COMAddins

It's a collection you can access to acquire a pointer to a given add-in.

Here's a link to more resources to help you:


Re: Visual Studio Tools for Office Unloading the VSTO Appdomain in Outlook


Hey John.

I am still struggling with how I unload/remove the com adding from the collection.

Outlook.ComAddins collection has no REMOVE methods from the collection.

Outlook.ComAddIns.Item(indx) has no remove/unload method.

I looked in your blog - most of the stuff there I am already aware of (been working with VSTO for quite a while now, from alpha days where Outlook addins were code named "Elixir" :) )

Can you point me to a specific article on this subject

The more I think about it the less I feel this is at all feasible.

This is a sort of a "self unload" mechanism I want to implement, where the addin that was just loaded will perform authorization checks and will REMOVE iteself from the ComAddin List and will release the acquired resources.

Is there a way to do this

Thanks again for your help...


Re: Visual Studio Tools for Office Unloading the VSTO Appdomain in Outlook

Andrew Whitechapel - MSFT

Hi Steiner

As you specify "ThisApplication_Startup", it's clear that this is a VSTO 2005 Outlook add-in you're building, not a VSTO 2005 SE add-in. While the technique of using the COMAddIns collection is generically useful, it is not supported in VSTO 2005 Outlook add-ins. So, you cannot unload this type of add-in using the COMAddIns collection approach. You also cannot use this technique to unload a VSTO 2005 SE add-in. VSTO 2005 SE add-ins do support the underlying COMAddIns exposure (via a new virtual method called RequestComAddInAutomationService), but the intention is to provide indirect access to this only in order to provide access to explicitly exposed functionality of the add-in, and _not_ to allow you to disconnect or unload the add-in.

There is no easy way to programmatically remove a VSTO 2005 add-in after it has been loaded. Further, there is normally no simple way to remove managed code from memory at all, apart from unloading the appdomain. If you could unload the appdomain, that would by extension unload all the assemblies in the appdomain. However, attempts to unload the appdomain from within the add-in itself will inevitably throw ThreadAbortExceptions or AppDomainUnloadedExceptions, and I would certainly advise you strongly not to use this approach.

Each VSTO add-in is placed in its own appdomain, partly for isolation reasons, so attempting to unload the appdomain from another appdomain is also problematic.

So, your current solution of simply returning from ThisApplication_Startup, is certainly the simplest approach.

Other options you might consider include approaches such as registering the add-in as load-on-demand. That is, using LoadBehavior=8 (by default, it would be set to 3). The purpose of this setting is to indicate that the add-in should be loaded and connected when the host application requires it, for example, when a user clicks on a button that uses functionality in the add-in. I'm not sure if this would meet your needs, but it's one option you can explore.

Another option would be to architect your solution so that the add-in assembly itself is extremely small, and only has enough code in it to offer say a button. Then, when the user clicks the button, you explicitly load the remaining assemblies which contain the bulk of the functionality. This is broadly similar to the previous option except that the mechanism is completely under your control, instead of relying on registry settings. You could even use this approach to load different assemblies conditionally - for example, depending on which user is running the app, or what roles the user belongs to, or any other business context.

Hope that helps