Is there a way to permanently prevent Outlook 365 from disabling our add-in due to load time? RRS feed

  • Question

  • We have a VSTO add-in that many of our clients are now using with Office 365. Unfortunately, Office 365, and in particular Outlook, is disabling our add-in when they start it after a reboot.

    I believe we're getting charged for the .NET Framework startup time, as starting Outlook is the first thing most of our clients "do" (usually automatically) upon a reboot. In the past, we've used the techniques described here to prevent the add-in from getting disabled, but those don't seem to work with Office 365.

    In addition, there is no longer an option on the user's end to never disable the add-in - Office only offers a 30 day deferment, at which point it'll try to disable the add-in again, which will succeed if the user isn't paying attention to what the dialog says (which, of course, happens way too often). There used to be an option to "never disable", but it's apparently been removed from Office 365 for some reason.

    Is there any way to prevent Outlook from disabling our add-in just because the .NET Framework takes a second or two to load the first time? Our add-in is security related, so this is a major problem for some of our clients.


      Michael Whalen

    Thursday, June 20, 2019 3:25 PM

All replies

  • Hello Michael,

    I don't think the .net framework is the cause of the issue in this case. To make sure it is caused by the .net framework I'd recommend creating a dummy clean add-in without any heavy event handlers and see how it is loaded by Outlook at a cold startup of .net framework. Does it work correctly?

    After you answer this question you may move forward with troubleshooting. I'd recommend using secondary threads where possible and implement a lazy initialization per request or at first usage. Starting from Outlook 2013, the application monitors add-in performance counters such as add-in startup, shutdown, folder switch, item open, and iteration timing. For example, if the median startup time exceeds a specified amount, then Outlook will disable the add-in and display a notification to the user that an add-in has been disabled. The user has the option of always enabling the add-in, so that Outlook will not disable the add-in even if the add-in exceeds the performance threshold. So, I'd recommend avoiding tight places/event handlers to prevent add-in from disabling by Outlook. 

    profile for Eugene Astafiev at Stack Overflow, Q&A for professional and enthusiast programmers

    Thursday, June 20, 2019 4:47 PM
  • If they are starting Outlook for a second time (i.e. without a reboot), then our add-in starts in less than .3 seconds on average - it's only the first start of an Office product after a reboot where we see the problem, and for our clients, that's usually Outlook. That is why I believe the .NET Framework initialization is the issue.

    And it's specifically a problem with Office 365 because the "do not disable ever" option has been removed - they can now only defer the disabling for 30 days, at which time Office will try to disable the add-in again. Is there a way to get around that and permanently prevent Office 365 from trying to disable our add-in? That's really all we want at this point - to be able to do what we could do with Office 2013 and Office 2016 again.

    Monday, June 24, 2019 2:30 PM
  • If you think .Net cold startup may impact on slow startup of your add-in I'd highly recommend testing a newly created clean VSTO add-in in isolation. So, you could see the add-in is not disabled and started very quickly.

    For the second point, I'd suggest posting to .

    profile for Eugene Astafiev at Stack Overflow, Q&A for professional and enthusiast programmers

    Tuesday, June 25, 2019 8:38 AM
  • We've done that experiment multiple times. This is an issue that's been a problem for a small number of our clients for more than ten years now. It's only recently that it's become an unsolvable problem as the remedies were removed from Office 365 for some reason. 

    I'll try with the other forums to see if there's any info I can get there. I guess I was hoping some other developer on the MSDN forums might have a solution, rather than having to request a feature be restored - it's making things very hard on our clients.

    Thursday, June 27, 2019 4:33 PM