2

We have a .NET Framework VSTO plugin for Outlook that adds a button to the Ribbon to POST e-mails and metadata to an API. We deployed it using a validated code signing cert from SSL.com and a ClickOnce installer. We have tried Load at Startup and Load on Demand, but each yields issues. After installing the plugin on Windows 10 production clients (beta tester staff workstations), our plugin:

When using Load at Startup

The startup time eventually lands the plugin in the slow and disabled COM add-ins purgatory, despite our ultralight async init that takes milliseconds on local. One theory is that we are taxed for loading .NET Framework on clients that do not already have it loading on startup.

When using Load on Init

The plugin shows up in the Outlook Ribbon and functions as expected for a day or two until it eventually disappears from the Ribbon with no errors logged in either our logs or the Windows Event logs. At this point, the plugin is still installed, shows up everywhere add-ins/COM add-ins are managed throughout the Outlook UI, and in the Windows registry, add/remove programs, etcetera.

We are wide open to feedback on what could cause either behavior and hoping for ideas help to troubleshoot this further.

Been through posts like this: How to troubleshoot a VSTO addin that does not load? but haven't met with success yet.

Thanks

FlashJordan
  • 137
  • 2
  • 8

1 Answers1

0

If you want .Net out of the picture, you can either rewrite the addin in an unmanaged language (e.g. VC++ or Delphi), or you can create a stub addin in an unmanaged language and have it load you addin while Outlook is not looking. See Using IManagedAddin in VC++ to load VSTO VBA add-ins

Also note that addins don't just get disabled while Outlook is running unless it crashes in a spectacular way. Have you looked at the Outlook entries in the Windows Event log? It lists the disabled addins and the reason why they are disabled.

Dmitry Streblechenko
  • 62,942
  • 4
  • 53
  • 78
  • Appreciate the feedback. Re-writing the plugin from scratch is out of the question at this time. Based on personal experience, these statements are not accurate: ```Also note that addins don't just get disabled while Outlook is running unless it crashes in a spectacular way. Have you looked at the Outlook entries in the Windows Event log? It lists the disabled addins and the reason why they are disabled.``` -- One of our beta testers just left for lunch with the plugin fully operational and Outlook open, and when she came back, it was gone and there was nothing in the logs. See OP RE logs. – FlashJordan Dec 22 '21 at 23:18
  • Does Outlook still lists your addin in the `Application.COMAddins` collection? You can check it in Outlook Spy (click Application, select COMAddins, click Browse, go to the IEnumVariant tab and double click on your addin). – Dmitry Streblechenko Dec 23 '21 at 04:44
  • Everything _appears_ to be in order from the registry to the UI, with one obvious exception: the plugin is missing from the ribbon. – FlashJordan Jan 03 '22 at 17:04