Outlook disables VSTO addin, complains of load time

Question

I have a very strange problem with an AddIn I developed.

Clients complain of the AddIn being disabled by outlook because of slow loading times but in my code (1.2s on avrg), I don't have any other custom codes running during start up apart from AddIn Express generated code which can be seen below.

 private void ThisAddIn_Startup(object sender, System.EventArgs e)
        {
            logger.Debug("Startup called");
            this.AddInStartup();
            #region Add-in Express Regions generated code - do not modify

            this.FormsManager = AddinExpress.OL.ADXOlFormsManager.CurrentInstance;
            this.FormsManager.OnInitialize += new AddinExpress.OL.ADXOlFormsManager.OnComponentInitialize_EventHandler(this.FormsManager_OnInitialize);
            this.FormsManager.Initialize(this);
            #endregion
            logger.Debug("Exit Startup");
        }

Also, I have a ribbon Ribbon (Button), that gets loaded.

All functionality codes for the addIn such as login, webservice calls are only performed when outlook is opened with the Ribbon button clicked.

Are there any underlying issues i may have looked past or possible external reasons not related to my code where outlook will complain of my addIn starting up slow when all that happens is just the ribbon being loaded during outlook start time ?

Eugene Astafiev Eugene Astafiev · Accepted Answer · 2016-05-16T13:44:34

There are multiple reasons why your add-in starts slowly....

But the very first thing to start with is to remove any Add-in Express code and see how much time it takes to load. Do you get the same picture with a newly created add-in project without Add-in Express assemblies?

I'd suggest applying common approaches for increasing the overall add-in performance such as:

Consider using the Native Image Generator (Ngen.exe) on your application. Using Ngen.exe means trading CPU consumption for more disk access because the native image generated by Ngen.exe is likely to be larger than the MSIL image. To improve the warm startup time, you should always use Ngen.exe on your application, because this avoids the CPU cost of JIT compilation of the application code.
If an assembly is not installed in the Global Assembly Cache (GAC), there are delays caused by hash verification of strong-named assemblies and by Ngen image validation if a native image for that assembly is available on the computer. Strong-name verification is skipped for all assemblies installed in the GAC. For more information, see Gacutil.exe (Global Assembly Cache Tool).
Authenticode verification adds to the startup time. Authenticode-signed assemblies have to be verified with the certification authority (CA). This verification can be time consuming, because it can require connecting to the network several times to download current certificate revocation lists. It also makes sure that there is a full chain of valid certificates on the path to a trusted root. This can translate to several seconds of delay while the assembly is being loaded. Consider installing the CA certificate on the client computer, or avoid using Authenticode when it is possible. If you know that your application does not need the publisher evidence, you do not have to pay the cost of signature verification.

See Application Startup Time for more information. Also take a look at tje following pages:

Outlook disables VSTO addin, complains of load time

1 Answers