none
Solve slow cold add-in startup time this way a good idea..? RRS feed

  • Question

  • I have a managed add-in that in worst cases takes a second to start due to .NET cold startup time.

    What about writing to HKCU\Software\Microsoft\Office\16.0\Outlook\Resiliency\DoNotDisableAddinList and HKCU\Software\Microsoft\Office\15.0\Outlook\Resiliency\DoNotDisableAddinList in the installer so that the add-in will not be disabled?

    Would that not work?

    Thursday, June 16, 2016 4:45 PM

All replies

  • I suppose it would work if the installer wrote that registry value for every user who fired up Outlook, not just the one who was logged on at the time your add-in was installed.
    Thursday, June 16, 2016 5:20 PM
  • Yea, that is the problem. It is a per-machine installation that is run using admin rights. Too bad I cannot make it to work.
    Friday, June 17, 2016 9:43 PM
  • I use the Visual Studio Installer to create MSI installs for my native C++ COM add-in projects.  I have found that this installer will create HKCU registry keys for any user of Outlook that starts the program after my add-in has already been installed for "all users".  As a bonus, it is also self-repairing.  If the registry keys are deleted or damaged, or even if the add-in DLL itself is deleted, MSI will reinstall the missing pieces automatically.
    Saturday, June 18, 2016 1:10 AM
  • Hi Dingoshark,

    What is your current issue? Did your original issue which is related with DoNotDisableAddinList has been resolved? If you change DoNotDisableAddinList, will it be disabled?

    Or, do you have a new issue related with writing registry for every user? If so, I would suggest you refer the suggestion from RLWA.

    Best Regards,

    Edward


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Monday, June 20, 2016 7:46 AM
  • Hello,

    The add-in startup time and Disabled Items list are entirely different things. If you want to decrease the startup time you need to follow the rules listed below:

    1. Use the Ngen.exe utility for building the native image.

    2. Check for Certificate Revocation List.

    3. Use multiple threads for initializing and running the code. Note, the Outlook object model can be used from the main thread only. You may trap into exceptions if you try to use it on secondary threads. That's because Office applications use the single-threaded apartment model.

    Read more about all these  points and beyond in the Resolving performance issues with loading Office add-ins (VSTO add-ins or Shared add-ins) article.


    [custom.development]

    Monday, June 20, 2016 5:38 PM
  • The add-in startup time and Disabled Items list are entirely different things.

    There's an impact if slow startup times exceed Outlook performance criteria and Outlook wants to disable the add-in.  Although the user is given a choice when this occurs, it seems that the OP wants to avoid the situation.

    If I remember correctly this issue relates to the OP's use of the NetOffice library. https://social.msdn.microsoft.com/Forums/office/en-US/cb704acc-aa01-4270-a766-6a723e5e56a1/long-addin-loading-even-though-doing-nothing?forum=outlookdev#efba596f-4982-4a55-a761-bb62a5d1eeb4

    • Edited by RLWA32 Monday, June 20, 2016 6:06 PM
    Monday, June 20, 2016 6:02 PM
  • Oh, thank you for the explanation, RLWA32...

    Anyway, adding DoNotDisableAddinList subkeys doesn't solve the main problem - a slow startup or poor add-in performance.


    [custom.development]

    Monday, June 20, 2016 6:54 PM
  • Anyway, adding DoNotDisableAddinList subkeys doesn't solve the main problem - a slow startup or poor add-in performance.

    Fair enough. 

    But as a practical matter, unless we're talking about several seconds I doubt that a typical user would perceive a difference between the performance of an add-in whose mean startup times over 5 successive iterations was < 1000 ms and one that failed to meet that criterion.

    Microsoft's use of performance criteria to make users aware that "slow" Outlook startup is not Microsoft's fault presents developers with problems for which the solution is not always within their control.

    Monday, June 20, 2016 7:10 PM