0

I've been developing the VSTO plugin for Outlook and on some customers' PCs ran into the slow loading issue (which is apparently a chronic disease for all managed office add-ins as CLR loading is counted towards the whole plugin loading time).

I've read about a workaround that there is a possibility to have the VSTO plugin loaded by setting its Connect property to true from a fast-loading Native COM add-in: https://blogs.msdn.microsoft.com/andreww/2008/04/19/delay-loading-the-clr-in-office-add-ins/

I've implemented it, however even after setting the Connect property of VSTO add-in to true from the Native add-in it is still not loaded. I have the following code that is executed at OnStartupComplete:

CComVariant vtItem("VSTOAddInName");

Office::COMAddInsPtr spCOMAddins;
m_spOutlook->get_COMAddIns(&spCOMAddins);
if (spCOMAddins) {
    Office::COMAddInPtr spCOMAddIn;
    if (spCOMAddins->Item(&vtItem, &spCOMAddIn) == S_OK)
    {
        spCOMAddIn->put_Connect(VARIANT_TRUE);
        // I see this message!
        MessageBoxW(NULL, L"Connected flag set", L"Native_Addin", MB_OK);
    }
}
return S_OK;

The m_spOutlook is defined as:

Outlook::_ApplicationPtr m_spOutlook;

I see the MessageBox, so I assume that Connect property is set, but the addin still does not load. I've tried to do t with all possible LoadBehavior settings and none of those work. So the question is whether this workaround supposed to work? Maybe I should execute it under a different callback than OnStartupComplete. It is fine for me tho have the plugin loaded few seconds after outlook start, I just need it loaded and not hit the 1 second startup limit.

I would really appreciate your help!

P.S. The load-once delay-loaded VSTO plugin (LoadBehavior=16) is only a partial solution for me as I need the button in the ribbon to be disabled on certain items, so I need the plugin to be really loaded. Also, sometimes the button is disappeared without any notable reasons and it requires end users to do some magic to get it back which is not an option for me.

Sergii Gulenok
  • 47
  • 7

1 Answers1

1

Instead, I'd suggest reviewing the source code of your existing VSTO solution. Move any business logic to secondary threads so Outlook could load the plug-in as fast as it can. Moreover, you can use standard .net mechanism for decreasing the startup time such as:

  • Use NGen.exe to move code generation from application startup time to installation time.
  • Utilize the GAC. 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).
  • Defer Initialization Operations. Consider postponing initialization code until after the main application window is rendered. Be aware that initialization may be performed inside a class constructor, and if the initialization code references other classes, it can cause a cascading effect in which many class constructors are executed.
  • 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.

You can read more about that in the Application Startup Time article.

Is your add-in shown in the Disabled Items list after the Connect property was set to true?

Microsoft Office applications can disable VSTO Add-ins that behave unexpectedly. If an application does not load your VSTO Add-in, the application might have hard disabled or soft disabled your VSTO Add-in.

Hard disabling can occur when an VSTO Add-in causes the application to close unexpectedly. It might also occur on your development computer if you stop the debugger while the Startup event handler in your VSTO Add-in is executing.

Soft disabling can occur when a VSTO Add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable a VSTO Add-in if it throws an unhandled exception while the Startup event handler is executing.

When you re-enable a soft-disabled VSTO Add-in, the application immediately attempts to load the VSTO Add-in. If the problem that initially caused the application to soft disable the VSTO Add-in has not been fixed, the application will soft disable the VSTO Add-in again. Read more about that in the How to: Re-enable a VSTO Add-in That Has Been Disabled article.

Did you try to enable the add-in manually? Do you get the same results?

Eugene Astafiev
  • 47,483
  • 3
  • 24
  • 45
  • I've done those: 1. NGENed all assemblies I ship with the plugin during installation. 2. All initialization is done within a thread. But I will try to check Gacutil and authenticode. From what I observed, the main contribution to the load time are standard .Net libraries, VSTO and PIA. All others (my own and 3rd party I use) are just a fraction of a time that is consumed: like 0.3-0.5 seconds out of total 1.4-1.6. On average one second is spent only to load CLI environment and it is already more than: my customers have issue with the blank VSTO plugin that does nothing but load itself. – Sergii Gulenok Oct 29 '16 at 16:54
  • I've followed your advices both at putting all the libraries in GAC as well as looked a little bit more thoroughly through my initialization code and found a place that despite being executed in a thread still blocked the main thread. Those two improvements had resolved the original issue (slow vsto startup time) completely. Thanks! – Sergii Gulenok Nov 07 '16 at 21:03