Exportieren (0) Drucken
Alle erweitern

Format der XML-Manifestdatei

Letzte Aktualisierung: Dezember 2013

Die XML-Manifestdatei beschreibt den Inhalt des Pakets und gibt an, wie der Inhalt des Pakets einer Verzeichnisstruktur für die einzelnen Rollen zugeordnet wird. Häufig wird eine für eine bestimmte Rolle bereitgestellte Datei in anderen Rollen benötigt. Das einzelne Manifest im neuen Paketformat ermöglicht es dem Ersteller, die duplizierte Datei genau einmal einzuschließen und anschließend deklarativ zu beschreiben, wie die betreffende Datei für mehrere Rollen bereitgestellt werden soll. Das neue Paketformat vereinfacht die Archivstruktur und ermöglicht es Paketerstellern, Archive zu optimieren, in denen Dateien rollenübergreifend oder innerhalb einer Rolle gemeinsam genutzt werden. Dies hat eine kleinere Paketgröße zur Folge, wodurch eine schnellere Bereitstellung in Windows Azure ermöglicht wird.

Gemäß der Konvention erhält die XML-Manifestdatei den Namen package.xml. Beim XML-Manifest kann es sich jedoch um eine beliebige Datei im Archiv handeln, solange von der Beziehung auf die XML-Manifestdatei verwiesen wird und die XML-Manifestdatei dem Schema entspricht.

In diesem Thema wird das Format der XML-Manifestdatei anhand von Beispielen beschrieben. Weitere Informationen zum Anzeigen des Schemas der XML-Manifestdatei finden Sie unter Schema der XML-Manifestdatei.

Das XML-Basisformat sieht wie folgt aus:

<?xml version="1.0" encoding="utf-8"?>
<PackageDefinition xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/windowsazure">
  <PackageMetaData />
  <PackageContents />
  <PackageLayouts />
</PackageDefinition>

Im Folgenden wird der XML-Namespace für die XML-Manifestdatei dargestellt:

http://schemas.microsoft.com/windowsazure

Das XML-Manifest enthält drei Abschnitte. Jeder Abschnitt ist eine Auflistung von benannten Ressourcen, wobei sämtliche Namen relative URIs darstellen; es gilt die Syntax "a/b/c…". Beim Untersuchen der Namen auf Gleichheit wird die Groß- und Kleinschreibung beachtet, und es sind die normalen Konventionen für Codierung und die Verwendung von Escapezeichen für URIs zu befolgen. In diesem Thema werden die drei Abschnitte der Reihenfolge nach wie folgt beschrieben:

PackageMetaData

Die PackageMetaData-Auflistung ist ein Schlüssel/Wert-Speicher, wobei sowohl die Schlüssel als auch die Werte Zeichenfolgen sind. Im Folgenden finden Sie ein Beispiel einer PackageMetaData-Auflistung:

<PackageMetaData>
  <KeyValuePair>
    <Key>http://schemas.microsoft.com/windowsazure/ProductVersion/</Key>
    <Value>1.7.30308.2000 </Value>
  </KeyValuePair>
</PackageMetaData>

Die Summe der UTF-8-Bytes, mit denen der Schlüssel und die Werte codiert werden, darf 1 MB nicht überschreiten. Paketprozessoren, bei denen die Größe der Metadaten 1 MB überschreitet, können von jedem Paketprozessor abgelehnt werden.

Zum Vermeiden von Namespacekonflikten müssen Metadatenschlüssel URIs sein, bei denen dieselben Konventionen wie für XML-Namespaces befolgt werden.

PackageContents

Die PackageContents-Auflistung beschreibt die Dateien, aus denen sich das Paket zusammensetzt. Hierzu zählen Dateiname, Länge, ein optionaler sha256-Hash des Inhalts und der Pfad. Im Folgenden finden Sie ein Beispiel einer PackageContents-Auflistung:

<PackageContents>
  <ContentDefinition>
    <Name>Content/Example/WithoutHash</Name>
    <ContentDescription>
      <LengthInBytes>123</LengthInBytes>
      <IntegrityCheckHashAlgortihm>None</IntegrityCheckHashAlgortihm>
      <IntegrityCheckHash/>
      <DataStorePath>File00</DataStorePath>
    </ContentDescription>
  </ContentDefinition>
  <ContentDefinition>
    <Name>Content/Example/WithHash</Name>
    <ContentDescription>
      <LengthInBytes>123</LengthInBytes>
      <IntegrityCheckHashAlgortihm>Sha256</IntegrityCheckHashAlgortihm>          <IntegrityCheckHash>AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8=</IntegrityCheckHash>
      <DataStorePath>File01</DataStorePath>
    </ContentDescription>
  </ContentDefinition>
</PackageContents>

Ein Inhaltselement besteht aus einem benannten Bytedatenstrom und BLOB-Inhaltsressourcen, für die keine Größenbeschränkungen gelten. Dieser Bytedatenstrom kann optional eine Integritätsprüfung aufweisen, mit der sichergestellt wird, dass die Bytes ordnungsgemäß und ohne Beschädigung transportiert wurden.

Gültige Werte für das IntegrityCheckHashAlgortihm-Element sind None und Sha256. Wenn None angegeben ist, muss das IntegrityCheckHash-Element ein leeres Element sein. Für Sha256 muss die Zeichenfolge eine Base-64-Codierung von Hashbytes sein. Diese Zeichenfolge muss XSD vom Typ xs:base64Binary sein.

Namen sind relative URIs, und bei ihrer Verarbeitung wird die Groß- und Kleinschreibung berücksichtigt. Jedes Inhaltselement verfügt über ein DataStorePath-Element, das einen relativen URI darstellt, der auf den Bytedatenstrom im OPC-Archiv für das betreffende Element verweist. Der Name des DataStorePath ist beliebig. Um sicherzustellen, dass OPC-Dateien in verschiedenen Dateisystemen problemlos entpackt und wieder gepackt werden können, sollten OPC-Elementnamen in US-ASCII codiert und bei Vergleich mit Berücksichtigung der Groß- und Kleinschreibung eindeutig sein. Zudem sollten Sie Kurznamen verwenden, um die Überschreitung von Limits für Dateisystempfade zu vermeiden.

PackageLayouts

Die PackageLayouts-Auflistung ordnet Inhaltsressourcen einem bestimmten Layout von Dateien und Verzeichnissen auf einem virtuellen Windows Azure-Computer zu. Das Dateilayout umfasst Erstellungszeit und Änderungszeit sowie einen relativen Pfad. Die Pfade sind als spezifisch für ein bestimmtes Zieldateisystem anzusehen. Da die Syntax des Pfads betriebssystemabhängig ist, müssen sie als nicht transparente Werte behandelt werden. Da Layouts lediglich eine Beschreibung der Zuordnung darstellen, ist die Größe eines Layouts proportional zur Anzahl der darin enthaltenen Dateien und nicht zur Größe des Inhalts. Das heißt, dass Paketersteller potenziell in der Lage sind, künftig alternative Layouts einzuschließen, z. B. ein Layout für Linux und ein Layout für ein Windows-Betriebssystem, sodass sie betriebssystemagnostische Pakete erstellen können. Für Windows Azure SDK 1.7 müssen die Pakete jedoch den Windows-Konventionen entsprechen.

Die PackageLayouts-Auflistung ordnet Paketinhalt einem bestimmten Layout von Dateien und Verzeichnissen auf einem virtuellen Windows Azure-Computer zu. Paketlayouts sind benannt, und ein Paket kann eine Reihe verschiedener Layouts besitzen. Jedes Layout beschreibt, wie der Bytedatenstrom eines Paketinhaltselements in eine Datei in einem Zieldateisystem extrahiert wird. Jedes Layout ist eine Liste eindeutiger Dateipfade, die den Benennungskonventionen des Zieldateisystems folgt. Paketersteller können potenziell alternative Layouts einschließen und betriebssystemagnostische Pakete erstellen. Ein Paket könnte beispielsweise ein Layout für Linux und ein Layout für ein Windows-Betriebssystem enthalten. Das Layout enthält zudem Dateimetadaten, wie Erstellungszeit und Änderungszeit (als UTC-Angabe) sowie Schreibschutzattribute.

Das folgende Beispiel einer PackageLayouts-Auflistung enthält zwei Layouts mit den Namen fileCollection1 und fileCollection2. Beide Layouts beschreiben die Erstellung von zwei Dateien aus den Paketressourcen Content/Example/WithoutHash und Content/Example/WithHash. Der Inhalt wird jedoch zwei unterschiedlichen Dateinamen zugeordnet. In fileCollection1 sind die Dateinamen in Bezug auf die Groß- und Kleinschreibung eindeutig. Bei fileCollection2 unterscheiden sich die Namen nur hinsichtlich der Groß- und Kleinschreibung. In diesem Beispiel wird veranschaulicht, dass das Verpackungsformat zwar agnostisch konzipiert wurde, dass jedoch Paketersteller, die Dateilayouts erstellen, die Konventionen des Zieldateisystems befolgen müssen. Das zweite Dateilayout, fileCollection2, kann nur in einem Betriebssystem extrahiert werden, in dessen Dateisystem die Groß- und Kleinschreibung beachtet wird. Insbesondere wird die im Argument FilePath codierte Zeichenfolge als nicht transparenter Schlüssel behandelt, der unter Berücksichtigung der Groß- und Kleinschreibung verglichen wird.

<PackageLayouts>
    <LayoutDefinition>
      <Name>fileColletion1</Name>
      <LayoutDescription>
        <FileDefinition>
          <FilePath>Readme.txt</FilePath>
          <FileDescription>
            <DataContentReference>Content/Example/WithoutHash</DataContentReference>
            <CreatedTimeUtc>2012-02-01T01:16:33.9633733Z</CreatedTimeUtc>
            <ModifiedTimeUtc>2012-02-01T01:16:33.9643734Z</ModifiedTimeUtc>
            <ReadOnly>false</ReadOnly>
          </FileDescription>
        </FileDefinition>
        <FileDefinition>
          <FilePath>ReadmeToo.txt</FilePath>
          <FileDescription>
            <DataContentReference>Content/Example/WithHash</DataContentReference>
            <CreatedTimeUtc>2012-02-01T01:16:33.9643734Z</CreatedTimeUtc>
            <ModifiedTimeUtc>2012-02-01T01:16:33.9643734Z</ModifiedTimeUtc>
            <ReadOnly>false</ReadOnly>
          </FileDescription>
        </FileDefinition>
      </LayoutDescription>
    </LayoutDefinition>
    <LayoutDefinition>
      <Name>fileColletion2</Name>
      <LayoutDescription>
        <FileDefinition>
          <FilePath>README</FilePath>
          <FileDescription>
            <DataContentReference>Content/Example/WithoutHash</DataContentReference>
            <CreatedTimeUtc>2012-02-01T01:16:33.9643734Z</CreatedTimeUtc>
            <ModifiedTimeUtc>2012-02-01T01:16:33.9643734Z</ModifiedTimeUtc>
            <ReadOnly>false</ReadOnly>
          </FileDescription>
        </FileDefinition>
        <FileDefinition>
          <FilePath>Readme</FilePath>
          <FileDescription>
            <DataContentReference>Content/Example/WithHash</DataContentReference>
            <CreatedTimeUtc>2012-02-01T01:16:33.9643734Z</CreatedTimeUtc>
            <ModifiedTimeUtc>2012-02-01T01:16:33.9643734Z</ModifiedTimeUtc>
            <ReadOnly>false</ReadOnly>
          </FileDescription>
        </FileDefinition>
      </LayoutDescription>
    </LayoutDefinition>
  </PackageLayouts>

Siehe auch

Anzeigen:
© 2015 Microsoft