1

In a published Word add-in, I am using the Office.context.document.settings.get method to retrieve data previously saved by the Office.context.document.settings.set and its corresponding Office.context.document.settings.saveAsync methods from Word Javascript API Version 1.1. When saving data to the Word document (specifically the webextension.xml file) on the same user setup (Word Version, Platform, OS, etc), the correct data can be retrieved without issue. However, when opening the same Word document and launching the same published add-in on another machine (for example, a different Word Version), the Office.context.document.settings.get method returns null, and a second webextension file is created (webextension2.xml).

I understand that when an add-in is loaded, Office uses the id from the manifest file as the key to make sure the data is not overwritten by another add-in, as described nicely in this Stack Overflow post. In my previously mentioned issue, the id, version, store and storeType attribute of the we:reference element in the webextension.xml file contain the correct data from our add-in's Manifest file. Somehow, it appears Office does not recognize this data as from the same add-in.

Any other ideas as to why the Office.context.document.settings.get is returning null in this case?

Sample xml webextension1.xml: sample xml (can no longer be identified as belonging to our application)

<we:reference id="id1234" version="3.0.0.0" store="en-US" storeType="OMEX"/>
<we:alternateReferences>
    <we:reference id="id1234" version="3.0.0.0" store="id1234" storeType="OMEX"/>
</we:alternateReferences>

webextension2.xml: sample xml (can be identified as created by our application)

<we:reference id="id1234" version="3.0.0.0" store="en-001" storeType="OMEX"/>
<we:alternateReferences>
    <we:reference id="id1234" version="3.0.0.0" store="en-001" storeType="OMEX"/>
</we:alternateReferences>

Additional Context

  • I only noticed this problem over the last week (the add-in has been published for ~3 years), so it may be attributed to a recent Word or office-js release.
  • I also posted this issue in the office-js repository.
gkarmie
  • 11
  • 3
  • A similar issue for Excel can be found [here](https://stackoverflow.com/questions/65720404/office-settings-not-retrievable-in-excel-online-when-created-and-set-in-excel-de). An important note is that this issue here and the one I linked to occurs when the add-in is installed via the Microsoft App Store, not sideloading during development. – gkarmie Jan 15 '21 at 08:09

2 Answers2

0

In my experience Word is lacking an API to store key-value pairs per-user across devices and across documents. Outlook has an API called Office.RoamingSettings which does exactly this, but it is not available in Word.

[1] https://learn.microsoft.com/en-us/office/dev/add-ins/develop/persisting-add-in-state-and-settings

I've also seen more issues around this recently. I use the localStorage api to share key-value pairs across documents (but this still does not work across devices).

Someone from Microsoft might be able to clarify this better.

James
  • 2,742
  • 1
  • 20
  • 43
  • Thanks a lot for your input. Interesting to hear that you are also experiencing more issues around your integration recently. – gkarmie Jan 14 '21 at 15:34
0

Just wanted to mention to anyone else viewing this in the future...the Microsoft team fixed this bug with a recent release.

gkarmie
  • 11
  • 3