Requirements-Element

Artikel
10/23/2024

Die Bedeutung dieses Elements hängt davon ab, ob es im Basismanifest, als untergeordnetes Element eines <VersionOverrides-Elements> oder als untergeordnetes Element des Override-Elements verwendet wird.

Tipp

Bevor Sie dieses Element verwenden, machen Sie sich mit angeben von Office-Hosts und API-Anforderungen vertraut.

Im Basismanifest

Bei Verwendung im Basismanifest (d. h. als direktes untergeordnetes Element von OfficeApp) gibt das <Requirements-Element> den Mindestsatz an Office JavaScript-API-Anforderungen (Anforderungssätze und/oder Methoden) an, die Ihr Office-Add-In von Office aktiviert werden muss. Das Add-In wird nicht auf einer Kombination aus Office-Version und -Plattform (z. B. Windows, Mac, Web und iOS oder iPad) aktiviert, die die angegebenen Methoden und Anforderungssätze nicht unterstützt.

Add-In-Typ: Aufgabenbereich, E-Mail

Als untergeordnetes Element eines VersionOverrides-Elements

Gibt bei Verwendung als untergeordnetes Element von VersionOverrides den Mindestsatz an Office JavaScript-API-Anforderungen (Anforderungssätze und/oder Methoden) an, die von der Office-Version und -Plattform (z. B. Windows, Mac, Web und iOS oder iPad) unterstützt werden müssen, damit die Einstellungen im <VersionOverrides-Element> , die die Basismanifesteinstellungen überschreiben, wirksam werden.

Stellen Sie sich ein Add-In vor, das anforderung A im Basismanifest und Anforderung B innerhalb von <VersionOverrides> angibt.

Wenn die Plattform und die Office-Version A nicht unterstützen, wird das Add-In nicht aktiviert, und Office analysiert den <Abschnitt VersionOverrides> des Manifests nicht.
Wenn sowohl A als auch B unterstützt werden, wird das Add-In aktiviert, und das gesamte Markup in versionOverrides<> wird wirksam.
Wenn A unterstützt wird, aber B nicht, wird das Add-In aktiviert, und ein Teil des Markups in VersionOverrides<> wird wirksam. Insbesondere werden untergeordnete Elemente der <VersionOverrides> wirksam, die basisbasierte Manifestelemente nicht überschreiben. Beispielsweise wird ein <WebApplicationInfo-Element> oder ein< EquivalentAddins-Element> wirksam. Alle untergeordneten Elemente der <VersionOverrides> , die ein Basismanifestelement überschreiben, z <. B. Hosts>, werden jedoch nicht wirksam. Stattdessen verwendet Office die Werte des Basismanifestmarkups, das andernfalls überschrieben worden wäre.

Add-In-Typ: Aufgabenbereich, E-Mail

Nur in den folgenden VersionOverrides-Schemas gültig:

Aufgabenbereich 1.0
Mail 1.0
Mail 1.1

Weitere Informationen finden Sie unter Versionsüberschreibungen im reinen Add-In-Manifest.

Diesen Anforderungssätzen zugeordnet:

AddinCommands 1.1 , wenn der übergeordnete <VersionOverrides-Typ> Taskpane 1.0 ist.
Postfach 1.3 , wenn die übergeordnete <VersionOverrides> den Typ Mail 1.0 hat.
Postfach 1.5 , wenn die übergeordnete <VersionOverrides> den Typ Mail 1.1 hat.

Hinweise

Das <Requirements-Element> dient in einem <VersionOverrides-Element> nicht, wenn es keine zusätzlichen Anforderungen angibt, die nicht in einem <Requirements-Element> im Basismanifest angegeben sind. Wenn die Office-Version und die Plattform die Anforderungen im Basismanifest nicht unterstützen, wird das Add-In nicht aktiviert, und das <VersionOverrides-Element> wird nicht analysiert. Aus diesem Grund sollten Sie ein <Requirements-Element> in einer <VersionOverrides> nur verwenden, wenn diese beiden Bedingungen erfüllt sind:

Ihr Add-In verfügt über zusätzliche Features, die mit der Konfiguration in einer <VersionOverrides> implementiert werden (z. B. Add-In-Befehle), die eine Methode oder einen Anforderungssatz erfordern, die nicht in einem <Requirements-Element> im Basismanifest angegeben ist.
Ihr Add-In ist nützlich und sollte (jedoch ohne die zusätzlichen Features) aktiviert werden, selbst in einer Kombination aus Plattform- und Office-Version, die die anforderungen für die zusätzlichen Features nicht unterstützt.

Tipp

Wiederholen Sie keine Anforderungselemente aus dem Basismanifest innerhalb einer VersionOverrides.Do not repeat Requirement elements from the base manifest inside a <VersionOverrides>. Dies hat keine Auswirkungen und ist potenziell irreführend, was den Zweck des <Requirements-Elements> innerhalb einer <VersionOverrides angeht>.

Warnung

Verwenden Sie vor der Verwendung eines <Requirements-Elements> in einer <VersionOverrides-Instanz> große Vorsicht, da bei Plattform- und Versionskombinationen, die die Anforderung nicht unterstützen, keine Add-In-Befehle installiert werden, selbst solche, die Funktionen aufrufen, die die Anforderung nicht benötigen. Betrachten Sie beispielsweise ein Add-In mit zwei benutzerdefinierten Menübandschaltflächen. Eine davon ruft Office-JavaScript-APIs auf, die in Anforderungssatz ExcelApi 1.4 (und höher) verfügbar sind. Die andere ruft APIs auf, die nur in ExcelApi 1.9 (und höher) verfügbar sind. Wenn Sie eine Anforderung für ExcelApi 1.9 in VersionOverrides<> angeben, wird keine Schaltfläche im Menüband angezeigt, wenn 1.9 nicht unterstützt wird. Eine bessere Strategie in diesem Szenario wäre die Verwendung der unter Laufzeitüberprüfungen beschriebenen Technik für die Unterstützung von Methoden und Anforderungsmappen. Der Code, der von der zweiten Schaltfläche aufgerufen wird, verwendet isSetSupported zuerst, um die Unterstützung von ExcelApi 1.9 zu überprüfen. Wenn dies nicht unterstützt wird, gibt der Code dem Benutzer eine Meldung, dass dieses Feature des Add-Ins in seiner Office-Version nicht verfügbar ist.

Hinweis

In Mail-Add-Ins ist es möglich, dass eine <VersionOverrides> 1.1 in einer <VersionOverrides> 1.0 geschachtelt wird. Office verwendet immer die höchste Version <VersionOverrides> , die von der Plattform und der Office-Version unterstützt wird.

Als untergeordnetes Element des Override-Elements

Ein <Requirements-Element> kann ein untergeordnetes Element eines Override-Elements im Kontext eines übergeordneten ExtendedOverrides-Elements sein. Ein <Override-Element> drückt eine Bedingung aus und kann als "If ... dann ..." Aussage. Wenn das <Override-Element> vom Typ RequirementTokenOverride ist (d. h., dass der xsi:type des übergeordneten Token-Elements ist RequirementsToken), gibt das untergeordnete <Requirements-Element> die Bedingung aus, und das Value Attribut ist das daraus folgende. Die erste <Außerkraftsetzung> im Folgenden lautet z. B. "Wenn die aktuelle Plattform FeatureOne Version 1.7 unterstützt, verwenden Sie die Zeichenfolge "oldAddinVersion" anstelle des ${token.requirements} Tokens in der URL der großelternlternen <ExtendedOverrides> (anstelle der Standardzeichenfolge "upgrade"). Weitere Informationen finden Sie unter ExtendedOverrides.

<ExtendedOverrides Url="http://contoso.com/addinmetadata/${token.requirements}/extended-manifest-overrides.json">
    <Tokens>
        <Token Name="requirements" DefaultValue="upgrade" xsi:type="RequirementsToken">
            <Override Value="oldAddinVersion">
                <Requirements>
                    <Sets>
                        <Set Name="FeatureOne" MinVersion="1.7" />
                    </Sets>
                </Requirements>
            </Override>
            <Override Value="currentAddinVersion">
                <Requirements>
                    <Sets>
                        <Set Name="FeatureOne" MinVersion="1.8" />
                    </Sets>
                    <Methods>
                        <Method Name="MethodThree" />
                    </Methods>
                </Requirements>
            </Override>
        </Token>
    </Tokens>
</ExtendedOverrides>

Add-In-Typ: Aufgabenbereich

Syntax

<Requirements>
   ...
</Requirements>

Enthalten in

Kann enthalten

Das <Requirements-Element> kann je nach Add-In-Typ die folgenden untergeordneten Elemente enthalten.

Element	Inhalt	E-Mail	TaskPane
mappe	Ja	Ja	Ja
Methoden	Ja	Nein	Ja

Siehe auch

Weitere Informationen zu Anforderungssätzen finden Sie unter Office-Versionen und Anforderungssätze.

Freigeben über