none
How can I deal with the 1000ms startup limit for a Outlook Add-In RRS feed

  • Question

  • Hello

    We had the problem that in rare cases when our VSTO Add-In starts we get an error telling us that our add-in started too slow.
    (See image[1])

    Because our Add-In does nothing more in the Initialization-Process than an empty VSTO-Project and i do not know how i could optimize this I have done some research about the problem.

    I have found that the problem could be, that while the Add-In is starting the .NET-Framework is loaded, which, depending on the hardware of the user, can take a while and crush the 1000ms-limit.
    Also i read that the verification of the certificate could add time while having a bad internet connection.

    As possible solutions for this I have found the option to add an entry to the registry key HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Resiliency\DoNotDisableAddinList

    But for me this sems very unclean because it forces Outlook ta always keep the add-in active even when some bad errors would occur.

    The "best" option i have found to this point is to inform the users via FAQ or something simmilar about the fact that this error message can appear and that they should simply reactivate the add-in.

    Is there a better solution for my current problem or which solution of the ones i found yet is recomendet?

    [1]https://social.msdn.microsoft.com/Forums/getfile/805582


    Friday, February 19, 2016 10:09 AM

Answers

  • Hello,

    > Because our Add-In does nothing more in the Initialization-Process than an empty VSTO-Project and i do not know how i could optimize this I have done some research about the problem.

    So, does an empty add-in project take the same amount of time for loading?

    Extending the add-in resiliency pillar of Outlook 2010, Outlook 2013 monitors add-in performance metrics such as add-in startup, shutdown, folder switch, item open, and invoke frequency. Outlook records the elapsed time in milliseconds for each performance monitoring metric.

    For example, the startup metric measures the time required by each connected add-in during Outlook startup. Outlook then computes the median startup time over 5 successive iterations. If the median startup time exceeds 1000 milliseconds (1 second), then Outlook disables the add-in and displays a notification to the user that an add-in has been disabled. The user has the option of always enabling the add-in, in which case Outlook will not disable the add-in even if the add-in exceeds the 1000 millisecond performance threshold

    Monitoring add-in performance for default disabling

    Outlook uses the following criteria to determine if it should disable an add-in. The user has the option of always enabling an add-in and exempting the add-in from the add-in disabling criteria.

    Criteria

    Threshold (in milliseconds)

    Description

    Startup

    1000

    Measures the time in milliseconds for the add-in to complete startup using the IDTExtensibility2_OnConnection event. By default, if the median time over 5 successive iterations exceeds the performance threshold, Outlook disables the add-in.

    Shutdown

    500

    Measures the time in milliseconds for the add-in to complete shutdown using the IDTExtensibility2_OnDisconnection event. Only applies to add-ins that request slow shutdown. Add-ins that use fast shutdown are not subject to this criteria. If the median time over 5 successive iterations exceeds the performance threshold, Outlook disables the add-in on the next startup of Outlook.

    Folder switch

    500

    Measures the time in milliseconds for the add-in to complete folder switch using the BeforeFolderSwitch and FolderSwitch events on the Explorer object. By default, if the median time over 5 successive iterations exceeds the performance threshold, Outlook disables the add-in.

    Item open

    500

    Measures the time in milliseconds for the add-in to complete opening an item using the Open event on an item. By default, if the median time over 5 successive iterations exceeds the performance threshold, Outlook disables the add-in.

    Invoke frequency

    1000

    Measures the time interval in milliseconds between the add-in making 10,000 successive invoke calls. By default, if the interval between 10,000 successive calls and the next is less than the performance threshold, Outlook disables the add-in. Unlike the other 4 criteria, this criterion does not incur taking a median value.

    Preventing an add-in from being disabled

    While most add-ins will not be disabled by the add-in disabling feature, you don’t want your add-in to be disabled consistently. Here are suggestions for improving add-in performance:

    • Prefer native COM add-ins over managed add-ins since managed add-ins must incur the overhead of loading the .NET Framework during Outlook startup.
    •  - If you have long-running tasks such as making an expensive connection to a database, defer those tasks to occur after startup.
    •  - If possible, cache data locally rather than making expensive network calls during the FolderSwitch and BeforeFolderSwitch events of an explorer, or Open events of an item.
    • Polling is an expensive operation, so always prefer an event-driven model over polling.
    •  - Be aware that all calls to the Outlook object model execute on Outlook’s main foreground thread. Avoid making long-running Outlook object model calls if possible. Note that in Outlook 2013, calls to the Outlook object model return E_RPC_WRONG_THREAD when the Outlook object model is called from a background thread.

    In particular, if you use Office developer tools in Visual Studio to create managed add-ins, be aware that the first add-in to load the CLR is likely to take a performance hit. Consider the following measures, and see the additional resources at the end of this document for details:

     - Load a managed add-in on demand.

     - Delay loading the CLR.

    •  - Use an MSI deployment package instead of ClickOnce.
    •  - If applicable, use a Fast Path to bypass schema validation, digital signatures validation in manifests, and automatic update checking. You can find more information about using the Fast Path in the blog post Performance Improvements Coming Soon to a Service Pack Near You (Stephen Peters).
    •  - If your add-in extends the ribbon and links in a large library, override ribbon reflection.

    Read more about that in the New in Outlook for developers article in MSDN.


    Friday, February 19, 2016 12:40 PM