Duplicated add-ins when workbook is initialized in Excel Online

[zpfaltersack]

Provide required information needed to triage your issue

If a workbook is initialized with an add-in using Excel Online first, then the add-in will be duplicated when opened in Excel Desktop.

Your Environment

• Platform [PC desktop, Mac, iOS, Office on the web]: PC Desktop, Office on the web, (have not tested Mac but wouldn't be surprised if it happens there)
• Host [Excel, Word, PowerPoint, etc.]: Excel
• Office version number: latest
• Operating System: 10/11
• Browser (if using Office on the web): chrome, edge

Expected behavior

Users should be able to seamlessly edit workbooks in Excel Online or Excel Desktop regardless of where the workbook was originally created, without getting an add-in duplicated.

Current behavior

As far as I can tell, it is theoretically possible to avoid this issue but there is no reasonable way one could expect a user to avoid getting Excel in a state where this happens. The issue is related to how the WebExtensions xml fragment is structured and has the same underlying DNA as the issue listed at #2878.

The difference here is that it happens even with only a single deployment mechanism: our customers deploy our add-in using Centralized Deployment as a Custom App.

The crux of the issue is that Excel Desktop and Excel Online register your add-in differently than each other. Excel Online seems more resilient to this but Excel Desktop gets confused and ends up loading the add-in a second time if it was originally associated with the workbook using Excel Online.

I have gone as far as I can with poking around with it. The issue mainly appears to be some incongruence between the casing of the store/storeType values as well as the alternateReferences. The most perplexing aspect of this is that it seems to be some ill-defined combination of these two items.

Steps to reproduce

1. Deploy a Custom App using Centralized Deployment (I am hosting the starter app from 'yo office', details provided in later link). I believe this will happen with any deployment mechanism since it's related to how the addin is defined in the xml, but this is how we deploy for our customers.
2. Start with a blank slate and clear your Excel Desktop web cache just to be sure.
3. In Excel Desktop, create a new workbook and associate your add-in with it. In my testing I use a custom function to ensure the add-in gets written in the xml.
4. Unzip the workbook and look at the webextension.xml file. Notice there is a single reference and no alternate references. Also notice the casing of the store/storeType attributes:
5. Open the original workbook in Excel Desktop and leave it running in the background (this may not be necessary).
6. Create a new workbook directly in Excel Online and associate the add-in with it (same mechanism as before, whichever you choose).
7. In Excel Online, select 'Open in Desktop App' to edit the workbook locally.
8. Once it is downloaded and opened in Excel Desktop, note that the add-in has been loaded twice (if using a custom tab, you'll see a second tab, if using the sample app, the ribbon will have two buttons for opening the taskpane).
9. Unzip the new workbook and look at the same WebExtensions fragment. Note the difference in casing for the original reference's store/storeType attributes. Also note the 'alternateReferences' that now exist in particular the different value for storeType.

Link to live example(s)

I expect this will happen with literally any add-in. I am hosting the sample custom functions app from 'yo office' just to demonstrate that even the most basic provided add-in samples will produce this behavior. The manifest can be found at: https://cosmosexcelfunctiontest.z5.web.core.windows.net/manifest.xml (Future readers: I make no guarantees on how long this will remain hosted)

Provide additional details

I've been able to manually modify the webextensions xml fragment to resolve this behavior. Here are my observations, but first, this is my understanding/theory of what the webextensions xml is trying to do (with respect to loading the add-in):

The 'reference' element describes the add-in to load. If it exists locally it is used; if it doesn't exist locally AND there is an 'alternateReferences' reference to use, it will use that to load up the add-in, and if there are no alternate references, then it will just load the add-in using the primary reference. Whether this is the intended process or not, this is the only thing that helps to understand the black box in the context of the following interventions.

In order to fix this, you will need to clear your web cache because this breaks Excel Desktop itself, not just the workbook that triggered the behavior.

Now that you've reset it, there are two different ways you can fix this problem:

1 Delete the content of the 'alternativeReferences' element. Rezip the file and open it up. Now you have two different workbooks associated with the add-in, using different casing for the store/storeType attributes (recall, the one built originally in Excel Desktop is uppercase 'EXCatalog' and the one in Excel Online is lowercase 'excatalog') but only one instance of the add-in is opened in Excel.

2 Modify the add-in reference in 'alternateReferences' and change the storeType value to be the same as the primary reference. Open the workbook and note the add-in is only registered once as expected.

Here is my theory about what is going on:

When Excel Desktop is looking at a workbook and identifying which add-ins are necessary, it is using a case-sensitive check for the id/store/storeType and so it is falling back on the alternate reference for the add-in that Excel Online listed. If there is no alternate reference, it ends up "downloading" the primary reference anyways, but however the add-in is cached, it is correctly handling casing such that it ends up resolving to the instance that already exists locally (though perhaps a refreshed version?). However, if there is an alternate reference, it will download that version. The inexplicable part to me, is why Excel Online creates an alternate reference using a different store type. This is what ultimately associates this issue with issue #2878 and its ilk.

There is no reason it should be a different store type, we have only deployed the add-in once and it is only consumed once.

Context

This materially affects our users. They employ workflows that go in between Excel Online and Excel Desktop, and workbooks are shared between folks that have preferences between one or the other. We cannot have our add-in trashing Excel for those users that prefer to use Excel Desktop. This is actively resulting in a poor experience for our users along with support requests.

[ghost]

Thank you for letting us know about this issue. We will take a look shortly. Thanks.

[gmichaud]

@zpfaltersack thanks for adding your voice. We also noticed different behaviours on Excel Online vs. desktop. Hopefully there are enough reports about these problems and improvements will be made!

[zpfaltersack]

Sure thing! And agreed. We've been aware of this for over a year, but the behavior was so inconsistent originally that we couldn't figure out a reliable repro. Our userbase is large enough now that all the various workflows being employed have made it a commonplace occurrence and also have provided enough data for us to finally understand it well enough to merit opening an issue for it. It took us awhile to be convinced we weren't doing anything wrong.

[zpfaltersack]

I found even more weird behavior as I've continued playing with it. If you clear the Excel Desktop web cache and do not initialize the add-in locally, then the behavior when opening an Excel Online workbook locally is even more odd.

If you initialize it this way, then Excel Desktop only gets one instance of the add-in registered... At first.

The odd thing is, if you now close that workbook so Excel Desktop is no longer running, and then start it back up and create a new local workbook, then the instance of the add-in that exists locally is "corrupted" (whatever that actually means...). More specifically, if your add-in has a custom function for example, then Excel Desktop does not actually seem to be aware that that function exists.

Only workbooks that are initialized in Excel Online will be able to use that instance of the add-in.

[yuc014]

Hi @zpfaltersack, I tested a central deployed addin and did repro your issue.

This is a known gap between excel online and desktop. I created an internal bug#7464296 to track it. Thanks.

And for another issue I cannot repro it. Normally, the addin only persists in the doc where you installed it, so if you close it and open a new workbook, then the new workbook shouldn't be associate with this addin. If you want use this addin in the new work book, it can be found under "Add-ins"->"My addins" tab.

[zpfaltersack]

Hi @yuc014, thank you for verifying the repro. When you say this is a known gap, does that mean it's documented somewhere? I never found anything that would explain this but can easily imagine missing it given the sheer amount of reading I was doing.

I have to say, I understand the security concerns around the same app from different stores etc, but this seems like the most basic use-case (ie, single deployment mechanism/store); it's hard for me to imagine this not being considered a high priority given how unintuitive it is for end-users (and developers for that matter). Is it something that's actively being worked on? Do you have any sort of idea when a resolution may be pushed out?

Regarding the other issue, I'm honestly not sure what to say about it. I'd attach a video but it doesn't seem worth it because it's literally just me opening Excel Desktop and having two instances of our ribbon. The only way to fix it is to flush the web cache on close so that it gets reset when Excel is restarted.

On that note, is there any way to get Excel to disassociate an add-in from a workbook? We're fortunate that we don't really use any of the state/data features outside of custom functions, which persist in the workbook itself, so we could "resolve" our current issues by removing the addin from the workbook and reassociating it in Excel Desktop (as opposed to Excel Online) since online seems more resilient to the desktop variant. This is obviously sub-par but would help us work with our customers until a real resolution has been deployed on your side. Manually modifying the xml is not a reasonable thing to expect our users to do, and at scale it's not something we can do internally either so ideally Excel itself has some way to do this but I haven't found anything that would seem to do this.

[gmichaud]

On that note, is there any way to get Excel to disassociate an add-in from a workbook? We're fortunate that we don't really use any of the state/data features outside of custom functions, which persist in the workbook itself, so we could "resolve" our current issues by removing the addin from the workbook and reassociating it in Excel Desktop (as opposed to Excel Online) since online seems more resilient to the desktop variant. This is obviously sub-par but would help us work with our customers until a real resolution has been deployed on your side. Manually modifying the xml is not a reasonable thing to expect our users to do, and at scale it's not something we can do internally either so ideally Excel itself has some way to do this but I haven't found anything that would seem to do this.

You can do this on Excel for Windows only. File->Info->Inspect Workbook. "Task Pane Add-Ins" is what you're looking for (it's checked by default). Once you click OK it will scan your workbook, and you will have the ability to remove the reference. It's not very intuitive, and a problem if your users are on a Mac.

Alternative is to do it manually, by renaming the .xlsx to .zip, and removing the web extensions file.

[zpfaltersack]

Thanks @gmichaud! That was exactly what I was looking for. Not ideal to have to do it but this will help us at least temper our users' frustrations for the time being.

[yuc014]

Hi @zpfaltersack, our engineers are dealing with this issue. Will update when have process.

And thanks @gmichaud for the workaround.

[wh1t3cAt1k]

@yuc014 since it's been more than a month, has there been an update on the fix for this bug? If yes, what are the fix versions of Excel Online & Excel Desktop, respectively, or will the fix be done in office.js directly?

[4tti]

Hello,

we want to support Excel online soon (as of now it is deliberately disabled for security reasons) and this seems to be show stopper ☹️

[montezdesousa]

Hello,

I'm having the same problem described in the issue.

gmichaud I tried the fix for Mac (removed webextension1.xml, also tried removing the whole webextensions folder), but i get the following prompts after zipping the file back to .xlsx and cannot open the file.

[gmichaud]

@montezdesousa which tool did you use to remove the XML file from the ZIP? It doesn't work for me from the Mac, had to use the Windows ZIP utility.

[montezdesousa]

@montezdesousa which tool did you use to remove the XML file from the ZIP? It doesn't work for me from the Mac, had to use the Windows ZIP utility.

Thanks for the hint. It works if I use WinZip for Mac and remove the webextensions folder. I was using the default zip tool on mac.

[shanshanzheng-dev]

Hi We'll close this issue. If you still need help, please let us know and we'll reopen this. Thanks.

[Wolfran]

Hello, I'm having the same problem described in the issue. Could you please reopen this?