Teilen über

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

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 für Microsoft 365 kann in Outlook-Produktions-Add-Ins verwendet werden. Es ist nur als Vorschau für Excel-, PowerPoint- und Word-Add-Ins verfügbar.

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. Das Markup zur Konfiguration eines benutzerdefinierten Menüs enthält beispielsweise ein <Items> Element, das mehrere untergeordnete <Item> Elemente haben 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> werden häufig in zwei fiktive Kategorien unterteilt. Das <VersionOverrides> Element ist eine Kategorie. Die 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 Eigenschaft der obersten Ebene "extensions" , die in ihren Zweck- 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. <Description> 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 <Override> Keine
"webApplicationInfo" Identifiziert die Web-App des Add-Ins, wie sie in Microsoft Entra ID 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 <Hosts>Elemente , <Requirements>und <ExtendedOverrides> sind Teil des Basismanifests im reinen Add-In-Manifest. Konzepte und Zwecke, die diesen Elementen zugeordnet sind, werden jedoch in der "extensions" -Eigenschaft des einheitlichen Manifests konfiguriert.

"extensions" Eigentum

Die "extensions" -Eigenschaft 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 "extensions" Eigenschaft angegeben, ebenso wie Anpassungen des Menübands der Office-Anwendung. Die Konfigurationszwecke der "extensions" Eigenschaft stimmen genau mit denen des <VersionOverrides> Elements im reinen Add-In-Manifest überein.

Hinweis

Der <VersionOverrides> Abschnitt des reinen Add-In-Manifests verfügt über ein "Double Jump"-System für viele Zeichenfolgenressourcen. Zeichenketten, einschließlich URLs, werden angegeben und erhalten eine ID im <Resources>untergeordneten Element von <VersionOverrides>. Elemente, die eine Zeichenfolge erfordern, verfügen über ein resid Attribut, das mit der ID einer Zeichenfolge im <Resources> Element übereinstimmt. Die "extensions" -Eigenschaft 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 "extensions" Eigenschaft 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 "extensions". Die vollständige Referenz zum einheitlichen Manifest finden Sie unter Referenz zum Schema des Microsoft 365-App-Manifests.

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. <Requirements> und <Sets> Keine
"requirements.scopes" Identifiziert die Office-Anwendungen, in denen das Add-In installiert werden kann. <Hosts> Keine
"ribbons" Die Menübänder, die das Add-In anpassen. <Hosts>, ExtensionPoints und verschiedene *FormFactor-Elemente Die "ribbons" -Eigenschaft ist ein Array anonymer Objekte, die jeweils die Zwecke dieser drei Elemente zusammenführen. Siehe "ribbons" 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) Nichts.
"autoRunEvents" Konfiguriert einen Ereignishandler für ein angegebenes Ereignis. <ExtensionPoint> (vom Typ LaunchEvent) Nichts.
"keyboardShortcuts" (Entwicklervorschau) Definiert benutzerdefinierte Tastenkombinationen oder Tastenkombinationen zum Ausführen bestimmter Aktionen. <ExtendedOverrides> Nichts.

"ribbons" Tisch

In der folgenden Tabelle werden die untergeordneten Eigenschaften der anonymen untergeordneten Objekte im "ribbons" Array 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 überein <CustomTab>.
"fixedControls" Konfiguriert die Schaltfläche eines integrierten Add-Ins für die Spamberichterstattung und fügt sie dem Outlook-Menüband hinzu. <Control> untergeordnetes Element von <ReportPhishingCustomization> Nichts.
"spamPreProcessingDialog" Konfiguriert das Vorverarbeitungsdialogfeld, das angezeigt wird, nachdem die Schaltfläche eines Add-Ins für die Spamberichterstattung im Outlook-Menüband ausgewählt wurde. <PreProcessingDialog> untergeordnetes 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

  • Last updated on