Office-Add-Ins-Manifest

  • Artikel

Jedes Office-Add-In verfügt über ein Manifest. Es gibt zwei Arten von Manifesten:

  • Nur Add-In-Manifest: Dies ist der einzige Manifesttyp, der derzeit für Nicht-Outlook-Add-Ins unterstützt wird. Das Format ist XML. Diese Art von Manifest kann nicht für eine App verwendet werden, die ein Add-In mit einer anderen Art von Erweiterung der Microsoft 365-Plattform kombiniert.
  • Einheitliches Manifest für Microsoft 365: Dies ist eine erweiterte Version des JSON-formatierten Manifests, das seit Jahren als Manifest für Teams-Apps verwendet wird. Add-Ins, die dieses Manifest verwenden, können mit anderen Arten von Erweiterungen der Microsoft 365-Plattform in einer einzelnen App kombiniert werden, die als Einheit installiert werden kann.

Hinweis

Office-Add-Ins, die das einheitliche Manifest für Microsoft 365 verwenden, werden direkt in Office im Web, in neuen Outlook unter Windows und in Office unter Windows, die mit einem Microsoft 365-Abonnement verbunden sind, Version 2304 (Build 16320.00000) oder höher unterstützt.

Wenn das App-Paket, das das einheitliche Manifest enthält, in AppSource oder im Microsoft 365 Admin Center bereitgestellt wird, wird ein reines Add-In-Manifest aus dem einheitlichen Manifest generiert und gespeichert, wenn das Manifest über eine gültige "alternateIcons"-Eigenschaft verfügt. Dieses Reine Add-In-Manifest ermöglicht die Installation des Add-Ins auf Plattformen, die das einheitliche Manifest nicht direkt unterstützen, einschließlich Office für Mac, Office auf Mobilgeräten, Abonnementversionen von Office unter Windows vor 2304 (Build 16320.00000) und unbefristete Versionen von Office unter Windows.

Der Rest dieses Artikels gilt für beide Arten von Manifesten.

Tipp

Die Manifestdatei eines Office-Add-Ins beschreibt, wie Ihr Add-In aktiviert werden soll, wenn ein Endbenutzer es installiert und mit Office-Dokumenten und -Anwendungen verwendet.

Eine Manifestdatei ermöglicht einem Office-Add-In folgendes:

  • Beschreibung von sich selbst durch die Bereitstellung einer ID, einer Version, einer Beschreibung, eines Anzeigenamens und eines Standardgebietsschemas

  • Legen Sie die für das Branding des Add-Ins verwendeten Bilder und die für Add-In-Befehle im Office-App-Menüband verwendete Symboldarstellung fest.

  • Geben Sie an, wie das Add-In in Office integriert ist, einschließlich benutzerdefinierter Benutzeroberflächen wie z. B. Menübandschaltflächen, die das Add-In erstellt.

  • Angabe der angeforderten Standardabmessungen für Inhalts-Add-Ins und der angeforderten Höhe für Outlook-Add-Ins

  • Deklaration der von der Office-Add-In benötigten Berechtigungen wie Lesen oder Schreiben in dem Dokument

Hinweis

Wenn Sie beabsichtigen, das Add-In in AppSource zu veröffentlichen und in der Office-Benutzeroberfläche zur Verfügung zu stellen, stellen Sie sicher, dass die Zertifizierungsrichtlinien für den kommerziellen Marketplace erfüllt sind. Damit das Add-In die Validierung besteht, muss es beispielsweise auf allen Plattformen funktionieren, die die Methoden unterstützen, die Sie definieren (weitere Informationen finden Sie im Abschnitt 1120.3 und auf der Seite zur Verfügbarkeit von Office-Add-Ins auf Anwendungen und Plattformen).

Anforderungen für das Hosting

Alle Image-URIs, z. B. für Add-In-Befehle, müssen die Zwischenspeicherung in der Produktion unterstützen. Der Server, auf dem das Image gehostet wird, sollte keinen Header zurückgebenCache-Control, der , no-storeoder ähnliche Optionen in der HTTP-Antwort angibtno-cache. Wenn Sie jedoch das Add-In entwickeln und Änderungen an Bilddateien vornehmen, kann das Zwischenspeichern verhindern, dass Sie Ihre Änderungen sehen, sodass die Verwendung von Cache-Control Headern bei der Entwicklung ratsam ist.

Alle URLs für Code- oder Inhaltsdateien im Add-In sollten SSL-gesichert (HTTPS) sein. Die Verwendung eines HTTPS-Endpunkts für Ihr Add-In ist zwar nicht in allen Add-In-Szenarien streng erforderlich, wird aber unbedingt empfohlen. Add-Ins, die nicht SSL-gesichert (HTTPS) sind, generieren Warnungen zu unsicheren Inhalten und Fehlern während der Verwendung. Wenn Sie planen, Ihr Add-In in Office im Web auszuführen oder ihr Add-In in AppSource zu veröffentlichen, muss es SSL-gesichert sein. Wenn Ihr Add-In auf externe Daten und Dienste zugreift, sollte es SSL-gesichert sein, damit die Daten bei der Übertragung geschützt sind. Selbstsignierte Zertifikate können für die Entwicklung und für Tests verwendet werden, sofern das Zertifikat auf dem lokalen Computer als vertrauenswürdig festgelegt ist.

Bewährte Methoden für die Übermittlung an AppSource

Stellen Sie sicher, dass die Add-In-ID eine gültige und eindeutige GUID ist. Im Internet finden Sie verschiedene Tools zur Generierung von GUIDs, mit deren Hilfe Sie eine eindeutige GUID erstellen können.

An AppSource übermittelte Add-Ins müssen auch eine Support-URL im Manifest enthalten. Weitere Informationen finden Sie unter Validierungsrichtlinien für an AppSource übermittelte Apps und Add-Ins.

Angeben von Domänen, die im Add-In-Fenster geöffnet werden sollen

Wenn Sie in Office im Web oder in Outlook unter Windows ausgeführt werden, kann Ihr Aufgabenbereich zu einer beliebigen URL navigiert werden. Wenn Ihr Add-In auf Desktopplattformen jedoch versucht, zu einer URL in einer anderen Domäne als der Domäne zu wechseln, die die Startseite hostet (wie in der Manifestdatei angegeben), wird diese URL in einem neuen Browserfenster außerhalb des Add-In-Bereichs der Office-Anwendung geöffnet.

Um dieses Verhalten (Office desktop) außer Kraft zu setzen, geben Sie jede Domäne an, die Sie im Add-In-Fenster im Manifest öffnen möchten. Wenn das Add-In versucht, zu einer URL in einer Domäne zu wechseln, die in der Liste enthalten ist, wird sie in Office im Web und Desktop-Office im Aufgabenbereich geöffnet. Versucht das Add-In, zu einer URL zu navigieren, die sich nicht auf der Liste befindet, wird die URL in Desktop-Office in einem neuen Browserfenster (außerhalb des Add-In-Bereichs) geöffnet.

Hinweis

Es gibt zwei Ausnahmen zu dieser Regel.

  • Sie gilt nur für den Stammbereich des Add-Ins. Wenn auf der Add-In-Seite ein iframe eingebettet ist, kann der iframe zu einer beliebigen URL weitergeleitet werden, unabhängig davon, ob er im Manifest aufgeführt ist, auch in Office Desktop.
  • Wenn ein Dialogfeld mit der displayDialogAsync-API geöffnet wird, muss sich die URL, die an die Methode übergeben wird, in derselben Domäne wie das Add-In befinden, aber der Dialog kann dann an eine beliebige URL weitergeleitet werden, unabhängig davon, ob es im Manifest aufgeführt ist, auch in Desktop-Office.

Geben Sie Domänen an, aus denen Office.js API-Aufrufe erfolgen

Ihr Add-In kann Office.js API-Aufrufe aus der Domäne des Add-Ins ausführen, auf die in der Manifestdatei verwiesen wird. Wenn Ihr Add-In über andere iframes verfügt, die auf Office.js-APIs zugreifen müssen, fügen Sie der Manifestdatei die Domäne dieser Quell-URL hinzu. Wenn ein iframe mit einer Quelle, die nicht im Manifest aufgeführt ist, versucht, einen Office.js API-Aufruf auszuführen, erhält das Add-In den Fehler Berechtigung verweigert.

Siehe auch