Many Office developers report performance issues with loading Office add-ins (VSTO add-ins or Shared add-ins) but most of the time delay is due to external factors. This blog post tries to list possible reasons for delay in add-in load.
1).Net Cold Start – There could be some delay due to time taken to load the assemblies/dependencies from disk the first time an Office application is launched. Cold start applies for the first time CLR loads into Office after system startup. Cold start time applies to any .Net application. In typical scenarios this overhead is only few seconds (4-5) but it can be more depending upon the assemblies referenced. Please refer to article http://msdn.microsoft.com/en-us/magazine/cc337892.aspx for more details on this.
2) Check for Certificate Revocation List – Office PIA are signed using certificates and CLR validates that certificate used is valid before loading them. As part of this validation, it checks for a known list of malicious certificates (CRL list) and this could take time. To see if delay is being caused due to this, the user can disable CRL check Under IE Security -> “Check for publisher’s certificate revocation”. This can also be configured for Office application using generatePublisherEvidence configuration settings.
3) If you are using .Net 3.5 then there is a known issue with Framework 3.5 where .Net Crypto API was taking too long to validate the certificate– This has been fixed in hotfix http://support.microsoft.com/kb/981574/.
4) Actual add-in processing time – If too much processing is being done at startup (E.g call to web service are made from startup), then the add-in may load slowly. To verify this, a new blank “Hello World” add-in can be created to see if the issue occurs with this as well.
5) Delay due to Ribbon reflection – http://blogs.msdn.com/b/vsto/archive/2010/06/03/vsto-performance-ribbon-reflection.aspx.
6) Application startup time – (Host application startup time + startup time of other adds-in which are loading along with our add-in under investigation). We also need to make sure that any third party add-in is not creating startup delay.
7) Automatic Root Certificate Update – There could be delay caused due to Automatic Root Certificate Update. To see if this is causing the issue, turn off Automatic Root Certificate Update : http://technet.microsoft.com/en-us/library/cc734054(WS.10).aspx
8) If you are targeting VSTO SP1, you can take advantage of VSTO Fast Path which is a new way to load and launch VSTO add-ins that is much faster. Please refer to this blog post : http://blogs.msdn.com/b/vsto/archive/2010/11/30/performance-improvements-coming-soon-to-a-service-pack-near-you-stephen-peters.aspx for more details. Targeting .Net 4.0 may also help as explained in this blog post : http://blogs.msdn.com/b/vsto/archive/2010/04/23/why-should-i-upgrade-from-net-framework-3-5-to-net-framework-4.aspx.
If none of the workarounds listed above address the performance issue, or if this behavior is inevitable (E.g. calling web service on load), then here are few approaches which you can take to address add-in load performance issues –
1) Delay/Demand Loading of Add-Ins – This approach allows Office application to start quickly by loading the add-in only when it is needed (click on a user interface exposed by the add-in). Only when they want to use the add-in functionality, they will see some delay. Delay loading is described in following blog posts :
2) If functionality of add-in can be refactored into load time and event driven, this can help to further reduce the load time. Like if you are making a web service call during load but use the result data at later stage. You can move the web service calls to later stage.
3) If you are using Add-in for Mail merge/document builder kind of functionality, explore the option of using Open XML SDK which are more efficient..
4) If performance is degrading due to add-in code, try using Visual Studio Performance Profiler to find time consuming calls and take appropriate actions.