Issue with Office.context.document.settings.get

I'm reading settings from a Word Document using:

function callbackFunction(){
    var varValue = Office.context.document.settings.get("VariableName");
}

This call is made right after a call to :

Office.context.document.settings.refreshAsync(callbackFunction);

The settings are stored in a valid JSON String WebExtensionProperty: I can see the setting object in the Open XML productivity tool, without problem

We.WebExtensionProperty prop = new We.WebExtensionProperty(){ Name = "VariableName", Value = "{\"A\":\"1\"}" };
webExtensionPropertyBag1.Append(prop);

When I run my office-js add-ins from Visual Studio into Word (Using IE), the function returns the correct object from the JSON string stored in the WebExtensionProperty,
When I sideload my add-ins into Word (Using IE), the function also returns correctly, but
When I sideload my add-ins into Word online (Also using IE, even with Chrome), the function always returns null!
When I download the document from OneDrive, my property is still in the file.

I tried with simple variable in the json string, but I never managed to get Word Online ever return any value here, whereas Word on the Desktop always worked flawlessly.

Is there anything I need to do to 'authorize' the use of this function? Anyone having luck with this method in Word Online?

The settings I write into the file use is:

new We.WebExtensionStoreReference(){ Id = "MyUniqueId", Version = "1.0.0.0", Store = "\\\\localhost\\OfficeManifest", StoreType = "Filesystem" };

When I use it on Word online, could it be that the sideloading makes this same Add-ins not being in my UNC path, and therefore Word online can't load the value?

The manifest I use when sideloading is the same in all cases.

Thanks

This issue is a symptom of side-loading add-ins. A little background on this might help.

Certain add-in functionality, such as Settings, is keyed to a specific add-in. This allows you to ensure your settings don't get overwritten by another add-in that just happened to use the same setting name. When you retrieve your settings from Office, it is returning only those settings originally attributed to your add-in. This attribution is keyed off the add-in's ID from your manifest.

When an add-in is loaded from the Store or your tenant's add-in catalog, the add-in assigns the id for that add-in from your manifest file. Since this value doesn't change, it allows you to maintain settings across platforms and versions of your add-in.

Side-loading works differently. When you side-load an add-in, Office will assign it a randomly generated ID. This is done to ensure your development and production versions can co-exist side-by-side on the same machine. If Office used the ID from the manifest, it would effectively remove the production version of your add-in.

In most cases, the effects of side-loading will have no effect on your add-in. That is unless you're attempting to test Settings across machines/platforms where the automatically generated ID breaks the connection between your add-in and it's settings.

The workaround for this is to use a developer tenant and centrally publish your add-in there. This will automatically handle deployment of your add-in across each platform and ensure they all use the same ID value.