Disabling your Web Add-in if you have an Equivalent COM/VSTO Add-in

In previous post, I described how you can add code to your VSTO/COM add-in to disable your Web Add-in loaded from maniferst via the Office Portal:
Removing Web Add-in Ribbon Customization in Outlook for Windows (theofficecontext.com)

Well with Outlook for Windows, Office 365, version 16.0.13728.36136, you can now disable your Web Add-in via Policy settings.

Download Administrative Template files (ADMX/ADML) and Office Customization Tool for Microsoft 365 Apps for enterprise, Office 2019, and Office 2016 from Official Microsoft Download Center

Here is the path in the policy editor for this setting:

Once in the policy editor, you would set the value. If your OfficeJS Web Add-in has a GUID of {c5bc7737-0d79-4302-9e73-2a614941e914} and the COM add-in is called “My Full Featured Outlook Add-in“, you would set the values like this:

Specifically, the registry key it puts in place is this:

PATH: HKCU\SOFTWARE\Policies\Microsoft\Office\16.0\Outlook\addins\equivalentcomaddin
KEY (string/REG_SZ): {OfficeJS GUID}

For example, if I have an Outlook Web Add-in called “My Outlook Add-in” and it has the following manifest entry:

<?xml version="1.0" encoding="UTF-8"?>

Let’s say I have a full VSTO add-in called “My Full Featured Outlook Add-in” and it is registered as the following:

If you were to look at the Policy key after it is set you would have an entry like this:

KEY: {c5bc7737-0d79-4302-9e73-2a614941e914}
VALUE: My Full Featured Outlook Add-in

If it were an older traditional COM Add-in, like the top item: AccessAddin.DC, then it would look like this:

KEY: {c5bc7737-0d79-4302-9e73-2a614941e914}
VALUE: AccessAddin.DC

That is all you have to do if you have the newest builds of Outlook for Windows.

NOTE: Coming later in the year, will be an option to add this entry to your Web Add-in Manifest file the way you can with Excel and Word. 
NOTE: This is all covered in the latest Office add-ins community call.

Counting down…

With one month and one week to go, it is time to start moving off Windows XP and Office 2003. Here is another great article from Microsoft about how/why:

Support for Windows XP and Office 2003 ends April 8, 2014 — what’s next?

A few interesting highlights from the article:

  • Windows XP and Office 2003, however, have been supported for more than a decade, or since “Baywatch” went off the air.
  • Computers currently running Windows XP and Office 2003 won’t stop working on April 9, but over time security and performance will be affected: Many newer apps won’t run on Windows XP; new hardware may not support Windows XP; and without critical security updates, PCs may become vulnerable to harmful viruses, spyware and other malicious software that can steal or damage personal information and business data.
  • Office 365 — the next generation of familiar Office productivity applications in the cloud. The subscription-based service offers familiar Office tools and maintains file integrity and design when documents are edited by multiple people, and it provides enterprise-class security and privacy.

If you are considering the move and have questions about your Microsoft Office Integrated Line of Business Applications, there are many ways Microsoft and Microsoft partners can assist you in assessing and remediating these solutions.

You can learn more about Office 365 for your business here: http://blogs.office.com/office365forbusiness/


If you have been doing much work in VSTO and especially around Excel and embeddings, you may have been bit by this bug. Does this error look familiar:


“The program used to create this object is Excel. That program is either not installed on your computer or it is not responding. To edit this object, install Excel or ensure that any dialog boxes in Excel are closed.”

This error can be caused by the following:

  • A .NET3.5 Add-in or a .NET 4.0 Add-in
  • You have attached to the WorkbookOpen and/or WorkbookActivate events.
  • You are trying to edit/open/double-click on an embedded Excel instance inside a Word or PowerPoint document.

There have been several reports of this problem on the Microsoft MSDN site:

There are also a number of KB articles that document the problem and attribute it to specific programs:

The problem is specifically documented here:

Simple Solution

The basic simple answer is to place a Marshal.ComReleaseObject(Wb) at the end (or better, in the Finally block) of your event handlers. This will properly allow Word and excel to handle the OLE communication by not having VSTO hang on to an instance handle of the workbook, therefore causing the error.

And this is not carte blanche to start placing ComReleaseObject() all over your code. I have found VERY VERY few limited cases where using ComReleaseObject() in an add-in necessary. And this is one of them. Hot smile

Orphan Issue

It is not a panacea, either. Confused smile While it resolves the issues of OLE initialization and allows you to edit your Excel embedding in Word (as one example), it does not prevent one other scenario that I like to call “Orphaned Excel.” In this scenario, you edit your embedded Excel instance in another Window (usually via a right-click / Ole Object / Open). If you leave Excel open, return to Word and close the document, Excel should close. But in the VSTO COM/OLE scenario it may not – it will remain open with the embedded workbook still editable. However, it is orphaned an no longer associated with its container. Any edits will be lost.

That is where a solution I created for Excel/Word OLE interaction comes in here:

This add-in is very well commented and explains the following:

  • When a workbook is opened, it looks to see if it is embedded.
  • If it is, it connects to the running instance of Word, and gets a reference to the parent document.
  • A timer in the add-in will then continually check the status of the document
  • If the parent document is still opened, nothing happens. However, if Word is existed or the parent document is closed, the child embedding is forced closed.


However, and this is important note. For everything you do, you are in the sandbox with other kids. Sad smile Your add-in is loading in the same AppDomain as everybody else. If there is another VSTO 3.5/4.0 Add-in loaded in Excel and that add-in is not doing any of the above – well, your still going to have problems.

That is what makes this issue so vexing. Steaming mad You can play by all the rules, but you cannot prevent other kids from throwing sand. This is why I see some customers going to the extreme to manage out (disable) all other COM add-ins when they load their solution. But this does not work for HKEY_LOCAL_MACHINE Loaded add-ins.

There are few options and most involve a lot of code. I say, TEST. If your are in an Enterprise environment, test all your VSTO add-ins together, find code owners and get everyone on the same page. If it is a vendor add-in causing the problem, point them here. Smile