Freigeben über

Vergleichen Des reinen Add-In-Manifests mit dem einheitlichen Manifest für Microsoft 365

  • Artikel

Dieser Artikel soll Lesern, die nur mit dem Add-In-Manifest vertraut sind, helfen, das einheitliche Manifest zu verstehen, indem die beiden verglichen werden. Leser sollten auch Office-Add-Ins mit dem einheitlichen Manifest für Microsoft 365 sehen.

Hinweis

Das einheitliche Manifest unterstützt derzeit nur Outlook-Add-Ins und nur in Office, die mit einem Microsoft 365-Abonnement verknüpft sind und unter Windows, auf einem mobilen Gerät oder in Outlook im Web installiert sind. Wir arbeiten daran, die Unterstützung auf Excel, PowerPoint und Word sowie auf Outlook auf Mac und unbefristete Versionen von Office zu erweitern.

Schemas und allgemeine Punkte

Es gibt nur ein Schema für das einheitliche Manifest, im Gegensatz zum reinen Add-In-Manifest, das insgesamt sieben Schemas aufweist.

Konzeptionelle Zuordnung der einheitlichen Manifeste und nur Add-In-Manifeste

In diesem Abschnitt wird das einheitliche Manifest für Leser beschrieben, die mit dem reinen Add-In-Manifest vertraut sind. Einige Punkte, die Sie beachten sollten:

  • Das einheitliche Manifest ist JSON-formatiert.

  • JSON unterscheidet nicht wie XML zwischen Attribut- und Elementwert. In der Regel macht der JSON-Code, der einem XML-Element zugeordnet ist, sowohl den Elementwert als auch jedes der Attribute zu einer untergeordneten Eigenschaft. Das folgende Beispiel zeigt ein XML-Markup und sein JSON-Äquivalent.

    <MyThing color="blue">Some text</MyThing>

    "myThing" : {
    "color": "blue",
    "text": "Some text"
}

  • Es gibt viele Stellen im reinen Add-In-Manifest, an denen ein Element mit einem Pluralnamen über untergeordnete Elemente mit der Singularversion desselben Namens verfügt. Beispielsweise enthält das Markup zum Konfigurieren eines benutzerdefinierten Menüs ein <Items-Element> , das mehrere <untergeordnete Elemente des Elementelements> aufweisen kann. Das JSON-Äquivalent dieser Pluralelemente ist eine Eigenschaft mit einer Matrix als Wert. Die Elemente des Arrays sind anonyme Objekte, keine Eigenschaften mit dem Namen "Element" oder "Element1", "Element2" usw. Im Folgenden sehen Sie ein Beispiel.

    "items": [
    {
        -- markup for a menu item is here --
    },
    {
        -- markup for another menu item is here --
    }
]

Struktur der obersten Ebene

Die Stammebene des einheitlichen Manifests, das ungefähr dem <OfficeApp-Element> im reinen Add-In-Manifest entspricht, ist ein anonymes Objekt.

Die untergeordneten Elemente von <OfficeApp> sind häufig in zwei fiktive Kategorien unterteilt. Das <VersionOverrides-Element> ist eine Kategorie. Das andere besteht aus allen anderen untergeordneten Elementen von <OfficeApp>, die zusammen als Basismanifest bezeichnet werden. Auch das einheitliche Manifest weist eine ähnliche Unterteilung auf. Es gibt eine "extensions"-Eigenschaft der obersten Ebene, die in ihren Zwecken und untergeordneten Eigenschaften ungefähr dem <VersionOverrides-Element> entspricht. Das einheitliche Manifest verfügt auch über mehr als 10 weitere Eigenschaften der obersten Ebene, die zusammen die gleichen Zwecke wie das Basismanifest des reinen Add-In-Manifests erfüllen. Diese anderen Eigenschaften können zusammen als Basismanifest des einheitlichen Manifests betrachtet werden.

Basismanifest

Die Basismanifesteigenschaften geben Merkmale des Add-Ins an, die jede Art von Erweiterung von Microsoft 365 aufweisen soll. Dazu gehören Teams-Registerkarten und Nachrichtenerweiterungen, nicht nur Office-Add-Ins. Zu diesen Merkmalen gehören ein öffentlicher Name und eine eindeutige ID. Die folgende Tabelle zeigt eine Zuordnung einiger kritischer Eigenschaften der obersten Ebene im einheitlichen Manifest zu den XML-Elementen im aktuellen Manifest, wobei das Zuordnungsprinzip der Zweck des Markups ist.

JSON-Eigenschaft Zweck XML-Elemente Kommentare
"$schema" Identifiziert das Manifestschema. Attribute von <OfficeApp> und <VersionOverrides> Keine
"id" GUID des Add-Ins. <ID> Keine
"version" Version des Add-Ins. <Version> Keine
"manifestVersion" Version des Manifestschemas. Attribute von <OfficeApp> Keine
"name" Öffentlicher Name des Add-Ins. <DisplayName> Keine
"description" Öffentliche Beschreibung des Add-Ins. <Beschreibung> Keine
"accentColor" Keine Keine Diese Eigenschaft hat keine Entsprechung im reinen Add-In-Manifest und wird nicht im einheitlichen Manifest verwendet. Sie muss jedoch vorhanden sein.
„developer“ Identifiziert den Entwickler des Add-Ins. <ProviderName> Keine
"localizationInfo" Konfiguriert das Standardgebietsschema und andere unterstützte Gebietsschemas. <DefaultLocale> und <Außerkraftsetzung> Keine
"webApplicationInfo" Identifiziert die Web-App des Add-Ins, wie sie in Azure Active Directory bekannt ist. <WebApplicationInfo> Im reinen Add-In-Manifest befindet sich das <WebApplicationInfo-Element> in <VersionOverrides>, nicht im Basismanifest.
"authorization" Identifiziert alle Microsoft Graph Berechtigungen, die das Add-In benötigt. <WebApplicationInfo> Im reinen Add-In-Manifest befindet sich das <WebApplicationInfo-Element> in <VersionOverrides>, nicht im Basismanifest.

Die <Elemente Hosts>, <Requirements> und <ExtendedOverrides> sind Teil des Basismanifests im reinen Add-In-Manifest. Konzepte und Zwecke, die diesen Elementen zugeordnet sind, werden jedoch in der Eigenschaft "extensions" des einheitlichen Manifests konfiguriert.

Eigenschaft "extensions"

Die Eigenschaft "extensions" im einheitlichen Manifest stellt in erster Linie Merkmale des Add-Ins dar, die für andere Arten von Microsoft 365-Erweiterungen nicht relevant wären. Beispielsweise werden die Office-Anwendungen, die das Add-In erweitert (z. B. Excel, PowerPoint, Word und Outlook), in der Eigenschaft "extensions" angegeben, ebenso wie Anpassungen des Menübands der Office-Anwendung. Die Konfigurationszwecke der Eigenschaft "extensions" stimmen genau mit denen des <VersionOverrides-Elements> im reinen Add-In-Manifest überein.

Hinweis

Der <Abschnitt VersionOverrides> des reinen Add-In-Manifests verfügt über ein "Double Jump"-System für viele Zeichenfolgenressourcen. Zeichenfolgen, einschließlich URLs, werden angegeben und im untergeordneten Ressourcen-Element> von VersionOverrides eine ID< zugewiesen.>< Elemente, die eine Zeichenfolge erfordern, verfügen über ein resid Attribut, das der ID einer Zeichenfolge im <Resources-Element> entspricht. Die Eigenschaft "extensions" des einheitlichen Manifests vereinfacht die Dinge, indem Zeichenfolgen direkt als Eigenschaftswerte definiert werden. Das einheitliche Manifest enthält nichts, das dem <Resources-Element> entspricht.

Die folgende Tabelle zeigt eine Zuordnung einiger übergeordneter untergeordneter Eigenschaften der Eigenschaft "extensions" im einheitlichen Manifest zu XML-Elementen im aktuellen Manifest. Punktnotation wird verwendet, um auf untergeordnete Eigenschaften zu verweisen.

Hinweis

Diese Tabelle enthält nur einige ausgewählte repräsentative Nachfolgereigenschaften von "Extensions". Es handelt sich nicht um eine vollständige Liste aller untergeordneten Eigenschaften von "Erweiterungen". Eine vollständige Referenz zum einheitlichen Manifest finden Sie unter Einheitliches Manifest für Microsoft 365. Die Manifestreferenz, die alle neuesten Vorschaufeatures enthält, finden Sie unter Öffentliche Entwicklervorschau für das einheitliche Manifest für Microsoft 365.

JSON-Eigenschaft Zweck XML-Elemente Kommentare
"requirements.capabilities" Gibt die Anforderungssätze an , die das Add-In installieren können muss. , dass das Add-In installierbar sein muss. <Anforderungen> und <Sätze> Keine
"requirements.scopes" Identifiziert die Office-Anwendungen, in denen das Add-In installiert werden kann. <Hosts> Keine
"Menübänder" Die Menübänder, die das Add-In anpassen. <Hosts>, ExtensionPoints und verschiedene *FormFactor-Elemente Die Eigenschaft "Menübänder" ist eine Matrix anonymer Objekte, die jeweils die Zwecke dieser drei Elemente zusammenführen. Weitere Informationen finden Sie in der "Menübänder"-Tabelle.
"Alternates" Gibt Die Abwärtskompatibilität mit einem entsprechenden COM-Add-In, XLL oder beidem an. <EquivalentAddins> Siehe EquivalentAddins – Hintergrundinformationen finden Sie auch unter .
"runtimes" Konfiguriert die eingebetteten Runtimes , die das Add-In verwendet, einschließlich verschiedener Arten von Add-Ins, die wenig oder keine Benutzeroberfläche haben, z. B. benutzerdefinierte Add-Ins, die nur funktionen und Funktionsbefehle verwenden. <Runtimes>. <FunctionFile> und <ExtensionPoint> (vom Typ CustomFunctions) Keine
"autoRunEvents" Konfiguriert einen Ereignishandler für ein angegebenes Ereignis. <ExtensionPoint> (vom Typ LaunchEvent) Keine

Tabelle "Menübänder"

In der folgenden Tabelle werden die untergeordneten Eigenschaften der anonymen untergeordneten Objekte in der Matrix "Menübänder" den XML-Elementen im aktuellen Manifest zugeordnet.

JSON-Eigenschaft Zweck XML-Elemente Kommentare
"contexts" Gibt die Befehlsoberflächen an, die das Add-In anpasst. Verschiedene *CommandSurface-Elemente , z. B . PrimaryCommandSurface und MessageReadCommandSurface Nichts.
"tabs" Konfiguriert benutzerdefinierte Menübandregisterkarten. <CustomTab> Die Namen und die Hierarchie der Nachfolgereigenschaften von "tabs" stimmen eng mit den Nachfolgern von <CustomTab überein>.
"fixedControls" (Entwicklervorschau) Konfiguriert die Schaltfläche eines integrierten Add-Ins für die Spamberichterstattung und fügt sie dem Outlook-Menüband hinzu. <Steuern> des untergeordneten Elements von <ReportPhishingCustomization> Nichts.
"spamPreProcessingDialog" (Entwicklervorschau) Konfiguriert das Vorverarbeitungsdialogfeld, das angezeigt wird, nachdem die Schaltfläche eines Add-Ins für die Spamberichterstattung im Outlook-Menüband ausgewählt wurde. <Untergeordnetes PreProcessingDialog-Element> von <ReportPhishingCustomization> Nichts.

Ein vollständiges Beispiel für ein einheitliches Manifest finden Sie unter Beispiel für ein einheitliches Manifest.

Nächste Schritte