1
votes

We have created a simple Content Add-in (using office js api) that can be inserted in both Desktop and Online (browser) versions of PowerPoint.

The Desktop and Online versions share the same manifest. They have no difference in functionality and none have any special requirements defined in the manifest.

As they share the same manifest, they obviously share the same plugin id.

Never the less, add-in content inserted in web version version is not recognized when viewd in the desktop version. The error:

This add-in could not be started

And add-in content inserted in desktop version is not recognized when viewed in the web version. The error:

This add-in is not available in Office Online. Open this document in desktop version of Office to use the add-in.

Is this only because we use sideloading, or do we do something wrong?

1

1 Answers

0
votes

When you side-load an Add-in it automatically generates a random id for the add-in. So each time you side-load, you will end up with a new and unique id regardless of what was defined in the manifest.

Since side-loading is a dev/test rather than deployment scenario, this ensures that a side-loaded Add-in in dev/test won't conflict with any existing production Add-ins. It is very common for example for there to be a build in development, another build being tested, and the previous release in the Store.

For developing and testing scenarios that rely on a common id (the settings property bag is a prime example), the guidance is to use an Office 365 Developer Tenant and Central Deployment. This allows you to load your dev/test build in a non-production environment and deploy to multiple platforms (Windows, Mac, Web, etc.) using a common id.