CODEWITHSUNDEEP
outlookvsto
Shane
Shane

Reputation: 2351

How to avoid VSTO Outlook add-in from being disabled due to slow start up?

I have an add-in which needs to run some time consuming code during start up, since Outlook disables slow add-ins, what to avoid this somehow. Are there events I can respond to we don't count in Outlooks calculation of a slow add in? Or is utilizing threads the only way to go? Am a bit worried that threads if not used very carefully may interact badly with Outlook.

Upvotes: 0

Views: 234

Answers (1)

Dmitry Streblechenko
Dmitry Streblechenko

Reputation: 66255

Don't do anything like that on startup - the easiest workaround is to create a Timer object (use the Timer object from the Forms namespace, not System - you want the timer to fire on the main thread) and run your code when the timer event fires. By the time the event fires, you will be out of the startup callback that Outlook monitors, so it will never know. The user would still be blocked of course, so this can be only a temporary band-aid.

You can still use threads in you addin, you just need to make sure you don't touch OOM on the secondary threads. If your time consuming code does not need any Outlook objects, you can easily move it into a secondary thread. Otherwise Extended MAPI (C++ or Dephi only) or Redemption (I am its author - it wraps Extended MAPI and can be used from any language) are your only options. In case of Redemption, you can save the value of the Namespace.MAPIOBJECT property in a variable and then on a secondary thread create a new instance of the RDOSession object (it roughly corresponds to the Namespace object in OOM) and set its MAPIOBJECT property to the value saved on the main thread.

Upvotes: 2

Related Questions