How to improve the performance of an VSTO Outlook addin at startup / prevent Outlook from disabling AddIns

Question

As described in How to programmatically set registry setting to prevent Outlook from removing the VSTO Addin Outlook disables automatically AddIns which show poor performance on startup.

Microsoft describes basic rules for Addins which the developer should comply with: https://docs.microsoft.com/de-de/office/vba/outlook/concepts/getting-started/support-for-keeping-add-ins-enabled

Although what I don't understand is which code is executed when the startup gets loaded (during startup of Outlook)

The following 3 things get executed during startup of the Addin: 1.) All initialization of global variables 2.) The c'tor of the AddIn class (ThisAddIn) 3.) The method ThisAddIn_Startup

Is this correct?

Furthermore, I use

private static readonly log4net.ILog log = log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);

to initialize logging. Is this an expensive method regarding startup performance?

How can I find out which part (procedure calls) of this startup process takes most of the time? How do I use the profiler on an Addin? Do I guess I have to trace the Outlook.exe, correct? How can I extract the profiling info just for my AddIn?

I chose to explore this topic even deeper and removed the complete code in ThisAddIn_Startup, switched to Release (instead of Debug) in Visual Studio:

Guess what? The Add-in is still too slow! There are no c'tors, no initialization of any framework whatsoever, so we talk about a complete blank Add-in ... and still, Outlook fires up the message: This add-in is too slow!! Furthermore, I saw that you have to start OUtlook (without VisualStudio) several times so that OUtlook calculates a meantime for the startup of the add-in. But still, my complete clean Add-in takes 0,61sec to load which is too slow for Outlook. I have no idea what makes an empty Add-in take 0,61sec to start. I run OUtlook on an i7-CPU intel laptop (16 GB) so there see no reason for this.

Answer 1

It might not be you - keep in mind that that you get penalized for using .Net run-time; there is nothing you can do about that except switch to an unamanged language, such as VC++ or Delphi. I has success before with creating a stub COM addin in Delphi (load time about 20 ms) which loads a VSTO addin asynchronously (when Outlook is not looking) using IManageAddin interface.

Also keep in mind that VSTO run-time will validate the certificate used to sign your addin unless it resides in a secure location that requires admin rights to install to, such as a subfolder of the Program Files folder.

Answer 2

Is this correct?

You are absolutely right. You need to move any long-running or time-consuming tasks to another thread. Or just wait until everything is initialized by running a timer. In the timer's event, you can do any initialization stuff. Be aware that .NET includes four classes named Timer, each of which offers different functionality:

• System.Timers.Timer: fires an event at regular intervals. The class is intended for use as a server-based or service component in a multithreaded environment; it has no user interface and is not visible at runtime.
• System.Threading.Timer: executes a single callback method on a thread pool thread at regular intervals. The callback method is defined when the timer is instantiated and cannot be changed. Like the System.Timers.Timer class, this class is intended for use as a server-based or service component in a multithreaded environment; it has no user interface and is not visible at runtime.
• System.Windows.Forms.Timer (.NET Framework only): a Windows Forms component that fires an event at regular intervals. The component has no user interface and is designed for use in a single-threaded environment.
• System.Web.UI.Timer (.NET Framework only): an ASP.NET component that performs asynchronous or synchronous web page postbacks at a regular interval.

Please remember that the Outlook object model should be accessed from the main thread only. Based on this knownledge you must choose the timer class.

Another approach is to handle Outlook's events, for example, the Startup event is fired when Microsoft Outlook is starting, but after all add-in programs have been loaded. So, you can finish your initialization there.