1
votes

I've inherited care for a legacy Outlook add in, triggered by an issue reported by an end-user, stating that the add-in isn't activated anymore.

What I know

We have an old custom add-in:

  • Written in .NET 4 Client Profile
  • As a VSTO project
  • Written in VB.NET

It worked fine on Outlook 2010, the user's recently been updated to 2016.

Symptoms

  • After installation, loading Outlook takes much longer
  • You have to manually activate the add-in
  • If you do, the menu/ribbon is loaded correctly
  • On shutdown / restart of Outlook, the add in is inactivated again

It's config'd to be x86. I've tried switching that to x64, because I'm on a 64 bit OS, but then the addin just didn't load.

What I've looked into

I've googled a bit and found this link: CRM for Outlook Add-In keeps disabling

I think this quote describes what's going on:

Microsoft has some security measures in place to prevent slow add-ins from running inside Outlook. The issue is however that in many cases add-ins without fault are mistakenly marked as slow and disabled by Outlook, and if this is not immediately corrected when it first happens, Outlook may permanently disable them with no easy way to re-enable them.

I've researched with the help of an infrastructure/network engineer colleague to see if we can toggle the add-in to always enable, but no luck.


I've investigated eventviewer logs, I found this:

Outlook loaded the following add-in(s):

...
...

Name: AteamAddin
Description: AteamAddin
ProgID: AteamAddin
GUID: {00000000-0000-0000-0000-000000000000}
Load Behavior: 3
HKLM: 0
Location: file:///C:/Development/Deployment/AteamAddin.vsto
Boot Time (Milliseconds): 328

Followed by an entry with only my add-in on activating in Outlook, but with:

Boot Time (Milliseconds): 172

That's much slower than the second slowest, which loads in 47 milliseconds, but honestly, even 328 milliseconds isn't even that bad for a custom addin.


A weird thing is the empty GUID:

GUID: {00000000-0000-0000-0000-000000000000}

But I don't know if it's important. I've tried adding a Guid attribute to my ThisAddIn class, but no effect.

Question

What can I do to have Outlook 2016 accept the custom add-in?

2

2 Answers

1
votes

The load time looks good, I don't see anything strange there. Instead, I'd suggest making sure no exceptions are fired at runtime. Microsoft Office applications can disable VSTO Add-ins that behave unexpectedly. If an application does not load your VSTO Add-in, the application might have hard disabled or soft disabled your VSTO Add-in.

Hard disabling can occur when a VSTO Add-in causes the application to close unexpectedly. It might also occur on your development computer if you stop the debugger while the Startup event handler in your VSTO Add-in is executing.

Soft disabling can occur when a VSTO Add-in produces an error that does not cause the application to unexpectedly close. For example, an application might soft disable a VSTO Add-in if it throws an unhandled exception while the Startup event handler is executing.

When you re-enable a soft-disabled VSTO Add-in, the application immediately attempts to load the VSTO Add-in. If the problem that initially caused the application to soft disable the VSTO Add-in has not been fixed, the application will soft disable the VSTO Add-in again. Read more about that in the How to: Re-enable a VSTO Add-in that has been disabled article.

Also, I'd recommend making sure all the required prerequisites were included to the add-in package.

0
votes

The application needs two folders to move mails to, so it checks / creates it on startup of the add-in. It looks like Outlook 2016 is more restrictive in what is allowed. Checking these folders likely takes longer than Outlook allows, so the add-in is deactivated.

I moved the checking and creation of these folders to whenever a user opens any of the forms. That way it's way later in the process and that works without issue.