Freigeben über

So generiert Visual Studio ein App-Paketmanifest

  • Artikel

Wenn Sie ein Projekt mit Visual Studio erstellen, generiert Visual Studio ein Paketmanifest (AppxManifest.xml), das Informationen enthält, die das System zum Bereitstellen, Anzeigen oder Aktualisieren einer Universelle Windows-Plattform-App (UWP) benötigt.

Beim Entwickeln einer App mit Visual Studio

  • Package.appxmanifest
    Dies ist eine XML-Formatdatei, mit der Entwickler die Details einer App konfigurieren, z. B. Herausgeberinformationen, Logos, Prozessorarchitekturen usw. Dies ist eine leicht konfigurierbare, temporäre Version des App-Paketmanifests, das während der App-Entwicklung verwendet wird.
  • AppxManifest.xml
    Diese Datei wird vom Visual Studio Buildprozess generiert und basiert auf den Informationen in der Datei Package.appxmanifest. Dies ist die endgültige Version des App-Paketmanifests, das mit veröffentlichten und quergeladenen Apps verwendet wird. Wenn Updates an der Datei Package.appxmanifest vorgenommen werden, müssen Sie das Projekt neu erstellen, um die Updates in der datei AppxManifest.xml anzuzeigen.

Eine Übersicht über den Paketvorgang finden Sie unter Packen einer UWP-App mit Visual Studio.

Überprüfen des App-Manifests

Bevor Sie die App veröffentlichen können, müssen Sie alle Fehler korrigieren, die zu einem Fehler in einer der Visual Studio-Validierungsüberprüfungen führen. Wenn das Manifest von Visual Studio generiert wird, wird die App folgendermaßen überprüft:

  • Syntaktische Überprüfung
    Visual Studio bestätigt, dass alle Daten im App-Manifest dem App-Manifestschema entsprechen.
  • Semantische Überprüfung
    Visual Studio stellt basierend auf dem Informationskontext eine Anleitung für erwartete Daten bereit.

Hinweis

Wenn in diesen Abschnitten das gesuchte Feld nicht erwähnt wird, wird es entweder aus Daten generiert, die möglicherweise separat konfiguriert wurden, oder aus einem Standardwert aus dem Manifestschema.

Generieren des Manifestinhalts

Visual Studio füllt die Felder in den folgenden Tabellen auf, wenn die AppxManifest.xml-Datei für das App-Paket generiert wird.

Identity

Der Identity Abschnitt des App-Manifests enthält die folgenden Felder.

Feld BESCHREIBUNG
Name Der Name des Pakets, der in den folgenden Szenarien unterschiedlich aufgefüllt wird:
  • Dieses Feld ist standardmäßig eine generierte GUID.
  • Wenn Sie die App dem Microsoft Store zuordnen oder den Befehl Store –> App-Pakete erstellen... aufrufen und sich dann mit einem Entwicklerkonto anmelden, wird der Wert dieses Felds aus der zugeordneten App im Microsoft Store oder Partner Center abgerufen.
  • Wenn Sie den Befehl Store –> App-Pakete erstellen... aufrufen, sich aber nicht mit einem Entwicklerkonto anmelden, wird der Wert dieses Felds aus dem Quellmanifest übernommen.
Herausgeber Der Name des Herausgebers. Dieser Name wird in den folgenden Szenarien auf unterschiedliche Weise aufgefüllt:
  • Standardmäßig ist dieses Feld Ihr Benutzername.
  • Wenn Sie die App dem Microsoft Store zuordnen oder den Befehl Store –> App-Pakete erstellen... aufrufen und sich dann mit einem Entwicklerkonto anmelden, ist der Wert dieses Felds der Herausgeber, der dem Konto zugeordnet ist.
  • Wenn Sie den Befehl Store –> App-Pakete erstellen... aufrufen, sich aber nicht mit einem Entwicklerkonto anmelden, entspricht der Wert dieses Felds dem Betrefffeld des Testzertifikats, das Sie zum Signieren des App-Pakets verwendet haben.
Visual Studio unterstützt nur das Formular für den allgemeinen Namen (Common Name, CN) für den Herausgeber und fügt das Präfix "CN=" dem Feld herausgeber im Manifest hinzu.
Version Die Version der App, die erstellt wird. Dies wird in der Regel jedes Mal erhöht, wenn die App geändert und gepackt wurde. Um sicherzustellen, dass die Version ordnungsgemäß erhöht wird, verwenden Sie das Dialogfeld, das beim Aufrufen von Store –> App-Pakete erstellen... bereitgestellt wird, um Updates vorzunehmen.
ProcessorArchitecture Ein -Wert, der basierend auf der Buildkonfiguration generiert wird, die Sie für das Projekt angegeben haben. Wenn Projektverweise oder Dateiverweise im Projekt auf eine andere spezifische Architektur als das App-Paket abzielen, wird ein Buildfehler ausgelöst, und Sie müssen die Zielarchitektur des App-Pakets so ändern, dass sie für alle Verweise funktioniert.

Hier sehen Sie ein Beispiel für die Identity XML-Ausgabe:

<Identity Name="Microsoft.UWPAppExample"
          Publisher="CN=Microsoft Corporation"
          Version="1.0.0.0"
          ProcessorArchitecture="x86" />

Eigenschaften

Der Properties Abschnitt des App-Manifests enthält die Felder in der folgenden Tabelle.

Feld BESCHREIBUNG
PublisherDisplayName Diese Zeichenfolge wird in den folgenden Szenarien unterschiedlich aufgefüllt:
  • Standardmäßig ist dieses Feld Ihr Benutzername.
  • Wenn Sie die App dem Microsoft Store zuordnen oder den Befehl Store –> App-Pakete erstellen... aufrufen und sich dann mit einem Entwicklerkonto anmelden, stimmt der Wert dieses Felds mit der PublisherDisplayName-Zeichenfolge überein, die Ihrem Entwicklerkonto zugeordnet ist.
  • Wenn Sie den Befehl Store –> App-Pakete erstellen... aufrufen, sich aber nicht mit einem Entwicklerkonto anmelden, ist der Wert dieses Felds Ihr Benutzername, sofern Sie in der Datei Package.appxmanifest nichts anderes angeben.
DisplayName Diese Zeichenfolge wird in den folgenden Szenarien auf unterschiedliche Weise aufgefüllt:
  • Standardmäßig ist dieses Feld der Name des Projekts.
  • Wenn Sie die App dem Microsoft Store zuordnen oder den Befehl Store –> App-Pakete erstellen... aufrufen und sich dann mit einem Entwicklerkonto anmelden, wird der Wert dieses Felds gemäß den folgenden Regeln aufgefüllt:
    • Wenn Sie diesen Wert im Quellmanifest angeben und der Wert mit beginnt (was angibt, dass Sie diesen Wert lokalisieren möchten), stimmt der Wert dieses Felds mit @ dem angegebenen Wert überein.
    • Wenn die ausgewählte App nur einen einzigen Namen besitzt, besteht der Wert aus diesem Namen.
    • Wenn die ausgewählte App mehrere Namen hat, aber das Quellmanifest nicht lokalisiert ist, wird der Wert auf den Anzeigenamen im Quellmanifest festgelegt. Andernfalls wird der Wert auf den ersten reservierten Namen festgelegt.
  • Wenn Sie den Befehl Store –> App-Pakete erstellen... aufrufen, sich aber nicht mit einem Entwicklerkonto anmelden, wird der Wert dieses Felds aus dem Quellmanifest übernommen.
Logo Eine Visual Studio Vorlage wird standardmäßig verwendetAssets\StoreLogo.png. Dieser Wert sollte vom Entwickler in der Datei Package.appxmanifest angepasst werden.

Hier sehen Sie ein Beispiel für die Properties XML-Ausgabe:

<Properties>
    <DisplayName>UWP App Example</DisplayName>
    <PublisherDisplayName>Microsoft Corporation</PublisherDisplayName>
    <Logo>Assets\StoreLogo.png</Logo>
</Properties>

Anwendung

Ein App-Manifest kann mehrere Application Elemente enthalten, von denen jedes über einen Anzeigenamen verfügt, der auf der Kachel im Client angezeigt wird. Der Application Abschnitt des App-Manifests enthält die Felder in der folgenden Tabelle.

Feld BESCHREIBUNG
Id Diese Zeichenfolge wird in den folgenden Szenarien auf unterschiedliche Weise aufgefüllt:
  • Standardmäßig ist dieses Feld der Name des Projekts.
  • Wenn Sie die App dem Microsoft Store zuordnen oder den Befehl Store –> App-Pakete erstellen... aufrufen und sich dann mit einem Entwicklerkonto anmelden, ist der Wert dieses Felds der App-Name für die ausgewählte App, wenn und /Properties[@DisplayName]/Applications/Application[@DisplayName] im Quellmanifest übereinstimmen. Andernfalls ist der Wert mit dem Wert im Quellmanifest identisch.
  • Wenn Sie den Befehl Store –> App-Pakete erstellen... aufrufen, sich aber nicht mit einem Entwicklerkonto anmelden, entspricht der Wert dieses Felds dem Wert im Quellmanifest.
Ausführbare Datei Der Wert dieses Felds ist der Ausgabename der Projektassembly. Das ausführbare Token $targetnametoken$.exe, das in der Quellmanifestdatei (Package.appxmanifest) verwendet wird, wird beim Erstellen des Manifests durch den tatsächlichen Dateinamen ersetzt.
EntryPoint Dieser Wert basiert auf den generierten Executable Werten und Id .

Beispielausgabe Application :

<Applications>
    <Application Id="App" Executable="UWPAppExample.exe" EntryPoint="UWPAppExample.App">
        <!-- Other elements configured within the Application, such as Extensions, VisualElements, etc. -->
</Applications>

PackageDependency

Der PackageDependency Abschnitt enthält alle abhängigkeiten Windows Komponentenbibliothek für dieses Paket. Wenn Ihr Projekt beispielsweise über einen Verweis auf WinJS verfügt, ruft Visual Studio die Paketidentitätsinformationen der Abhängigkeiten ab, wenn das Manifest generiert wird. Visual Studio füllt diesen Abschnitt dann mit den Name Feldern und MinVersion für jedes abhängige Paket auf.

In einem nativen C++-Projekt fügt Visual Studio einen Verweis auf die Visual C/C++-Runtime hinzu:

<Dependencies>
    <PackageDependency Name="Microsoft.VCLibs.140.00.Debug" MinVersion="14.0.30035.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
</Dependencies>

Windows-Runtime Registrierungserweiterungen

Sie können Windows-Runtime Komponenten für Ihre Apps implementieren, aber Sie müssen diese Komponenten beim Betriebssystem registrieren, damit sie ordnungsgemäß ausgeführt werden. Um eine Windows-Runtime Komponente zu registrieren, müssen Sie die Registrierungsinformationen in den WinMD-Dateien und im App-Manifest speichern. Wenn ein Projekt eine Windows-Runtime Komponente implementiert, enthält die Buildausgabe des Projekts eine WinMD-Datei. Visual Studio extrahiert die Windows-Runtime Registrierungsinformationen aus der WinMD-Datei und generiert die entsprechenden Extension Elemente im App-Manifest.

Das System unterstützt zwei Arten von Servern: DLL-Server (prozessintern) und EXE-Server (prozessextern). Diese Server erfordern ähnliche, aber nicht identische Registrierungsinformationen, die in das App-Manifest kopiert werden müssen. Visual Studio unterstützt die Manifestgenerierung nur für DLL-Server, und für die Registrierung von DLL-Servern ist die DLLServer-Erweiterung erforderlich. Die folgenden Werte im App-Manifest werden von den WinMD-Dateien entnommen, um die DLLServer-Erweiterung zu erstellen:

  • DllPath
  • ActivatableClassId
  • ThreadingModel
  • ActivatableClass (ActivatableClassId-Attribut)

Im Folgenden finden Sie ein Beispiel der XML-Ausgabe:

<extension category="Microsoft.Windows.ActivatableClass">
    <dllServer>
        <dllPath>Fabrikam.dll</dllPath>
        <activatableClass activatableClassId="Fabrikam.MyClass" threadingModel="sta" />
    </dllServer>
</extension>

Weitere Informationen zu diesem Thema finden Sie unter Windows-Runtime Komponenten.

Ressourcen

Der Resources Abschnitt enthält einen Eintrag für jede Sprache, die von der Anwendung unterstützt wird. Im App-Manifest muss mindestens eine Ressourcensprache angegeben sein. Visual Studio generiert automatisch die Liste der unterstützten Sprachen auf Grundlage der Lokalisierungsinformationen im Projekt. Das In der Quellmanifestdatei (Package.appxmanifest) verwendete Ressourcensprachtoken "x-generate" wird beim Erstellen des Manifests durch den tatsächlichen Sprachcode ersetzt. Im Folgenden finden Sie ein Beispiel der XML-Ausgabe:

<Resources>
    <Resource Language="en-us">
    <Resource Language="fr-fr">
</Resources>

Der erste Eintrag in der Liste ist die Standardsprache für die App.

TargetDeviceFamily

Der TargetDeviceFamily Abschnitt enthält die folgenden Felder:

  • Name
  • Minversion
  • MaxVersionTested
<Dependencies>
    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.17763.0" MaxVersionTested="10.0.22000.0" />
</Dependencies>

Diese Elemente werden aus MSBuild aufgefüllt.

Siehe auch

Packen einer UWP-App mit Visual Studio
App-Paketarchitekturen
Windows 10-Paketmanifest-Schemareferenz