Exportieren (0) Drucken
Alle erweitern
Informationen
Das angeforderte Thema wird unten angezeigt. Es ist jedoch nicht in dieser Bibliothek vorhanden.

App-Pakete und -Bereitstellung (Windows-Runtime-Apps)

Applies to Windows and Windows Phone

Als Entwickler schreiben Sie keine Routinen für die Installation und Deinstallation einer Windows-Runtime-App. Stattdessen erstellen Sie ein App-Paket und senden es an den Store. Benutzer erwerben die App im Store in Form eines App-Pakets. Das Betriebssystem verwendet die Informationen im App-Paket, um Apps speziell für einzelne Benutzer zu installieren. So wird sichergestellt, dass alle Überreste der App vom Gerät entfernt werden, wenn die App von allen Benutzern deinstalliert wird.

Ein App-Paket ist ein Container, der auf dem OPC (Open Packaging Conventions)-Standard basiert. OPC definiert eine strukturierte Methode, um App-Daten und -Ressourcen in einer Standard-ZIP-Datei zu speichern. Informationen zur Verwendung von Microsoft Visual Studio zum Bereitstellen von App-Paketen finden Sie unter Bereitstellen von Windows-Runtime-Apps in Visual Studio.

Ab Windows 8.1 und Windows Phone 8.1 wird die Verpackung und Verteilung von Apps durch neue App-Bündel optimiert. Mithilfe von Ressourcenpaketen können Sie Kunden außerdem optionale Extras wie Lokalisierungen oder Ressourcen für hochauflösende Displays bieten. Für Kunden, die auf diese Extras verzichten können, bleibt in puncto Speicherplatz, Bandbreite und App-Einkauf alles beim Alten. Eine feste Verknüpfung optimiert auch die Installation Ihrer App, da eine Datenduplizierung vermieden wird, indem eine Datei höchstens einmal heruntergeladen wird.

Bereitstellen von Windows-Runtime-Apps

Das Windows-Runtime-App-Modell ist ein deklarativer zustandsgesteuerter Prozess, bei dem alle Installations- und Aktualisierungsdaten und -anweisungen für eine App in einem Gesamtpaket bereitgestellt werden. Bei diesem deklarativen Modell sind die Bereitstellungsvorgänge zuverlässig. Die in diesem Paket bereitgestellten Dateien sind unveränderlich. Dies bedeutet, dass die Dateien seit der Bereitstellung auf dem Gerät nicht geändert wurden. Da der Paketbesitzer keine benutzerdefinierten Aktionen und Codeabschnitte schreiben muss, wird die Anzahl der Fehlerpunkte reduziert.

Während des Aktualisierungsprozesses wird eine neue Version der App heruntergeladen und für das Profil des Benutzers installiert. Unmittelbar danach wird die alte Version vom Gerät entfernt. Anders als beim Windows Installer werden keine Patchdateien oder anderen Dateien verwendet, um eine Windows-Runtime-App bereitzustellen.

  • Applies to Windows

Hinweis  

Da Windows-Runtime-Apps in Windows unter dem Profil eines Benutzers installiert werden, besitzt jeder Benutzer die vollständige Kontrolle über seine Windows Store-Apps. Apps können installiert, aktualisiert und entfernt werden, ohne dass sich dies auf andere Apps des Benutzers auf dem Gerät auswirkt.

Weitere Informationen zur Bereitstellung finden Sie unter Bereitstellung für Windows-Runtime-Apps.

Windows-Runtime-App-Pakete (.appx)

Alle Komponenten, mit denen eine Windows-Runtime-App definiert wird, werden in einem Windows-Runtime-App-Paket gespeichert. Das Windows-Runtime-App-Paket hat die Dateierweiterung ".appx" und dient als Installationseinheit einer Windows-Runtime-App. Bei Windows-Runtime-App-Paketen handelt es sich um gezippte Containerdateien, die als Teilmenge der Standards ISO und ECMA OPC (Open Packaging Conventions) definiert sind. Jedes Windows-Runtime-App-Paket enthält die Nutzlastdateien der App sowie die Informationen, die zum Überprüfen, Bereitstellen, Verwalten und Aktualisieren der App benötigt werden. Normalerweise enthält jedes Windows-Runtime-App-Paket zumindest die folgenden Elemente:

App-Nutzlast

Codedateien und Objekte der App

Nutzlastdateien sind die Codedateien und Objekte, die Sie beim Entwerfen der Windows-Runtime-App erstellen.

App-Manifest

App-Manifestdatei (AppxManifest.xml)

Im App-Manifest werden die Identität der App, die Funktionen der App und die Informationen zur Bereitstellung und Aktualisierung deklariert. Weitere Informationen zur App-Manifestdatei finden Sie unter App-Paketmanifest.

App-Blockzuordnung

Blockzuordnungsdatei des App-Pakets (AppxBlockMap.xml)

In der Blockzuordnungsdatei sind alle App-Dateien aufgeführt, die im Paket enthalten sind, sowie die zugeordneten kryptografischen Hashwerte, die vom Betriebssystem zum Überprüfen der Dateiintegrität und zum Optimieren eines Updates für die App verwendet werden. Weitere Informationen zur Blockzuordnungsdatei finden Sie unter Blockzuordnung des App-Pakets.

App-Signatur

Datei mit digitaler Signatur des App-Pakets (AppxSignature.p7x)

Mit der Signatur des App-Pakets wird sichergestellt, dass das Paket und der Inhalt nach dem Signieren nicht geändert wurden. Wenn die Überprüfung des Signaturzertifikats zu einem Zertifikat einer vertrauenswürdigen Stammzertifizierungsstelle führt, wird anhand der Signatur auch angegeben, wer das Paket signiert hat. Der Signaturgeber des Pakets ist normalerweise der Herausgeber oder Autor der App.

Diese Elemente bilden eine eigenständige Windows-Runtime-App, die unter Windows 8 oder höher und Windows Phone 8.1 oder höher bereitgestellt werden kann. Sie erstellen die App-Nutzlast- und -Manifestdateien für Ihre App. Wenn Ihre App von Microsoft Visual Studio verpackt wird, werden die Blockzuordnung der App und die Signaturdateien dem Paket automatisch hinzugefügt. Sie können jedoch auch die eigenständigen Hilfsprogramme MakeAppx und SignTool verwenden, wenn Sie Ihre App manuell verpacken möchten. In den folgenden Abschnitten wird beschrieben, wie Sie Windows-Runtime-Apps verpacken und bereitstellen.

Paketidentität

Eines der wesentlichen Elemente des App-Pakets ist der Tupel mit fünf Bestandteilen, mit dem das Paket definiert wird. Dieser Tupel wird als Paketidentität bezeichnet und umfasst die folgenden Daten:

Name

Ein allgemeiner Name, der für das App-Paket verwendet wird. Beispiel: "myCompany.mySuite.myApp".

Hinweis  Dieser Name entspricht nicht zwangsläufig der Bezeichnung, die auf der App-Kachel angezeigt wird.

Publisher

Der Herausgeber bezieht sich auf den Herausgeber der Windows-Runtime-App. Meistens entspricht der Herausgeber dem Konto, das zur Registrierung für ein Entwicklerkonto verwendet wurde.

Version

Eine vierteilige Versionsbeschreibung (major.minor.build.revision), die zum Warten zukünftiger Versionen der App verwendet wird. Beispiel: "1.0.0.0".

Hinweis  Sie müssen alle vier Teile der Versionsbeschreibung verwenden.

ProcessorArchitecture

Die Zielarchitektur des App-Pakets. Der Wert kann "x86", "x64", "arm" oder "neutral" lauten. Häufig lautet dieses Feld "neutral", um alle Architekturen abzudecken.

ResourceID

Optional.

Eine vom Herausgeber angegebene Zeichenfolge, mit der die Ressourcen des App-Pakets angegeben werden. Dieser Teil des Tupels wird hauptsächlich verwendet, wenn das App-Paket über Objekte verfügt, die speziell für eine Region gelten, z. B. Sprachen.

Informationen für das manuelle Erstellen des Pakets finden Sie im Identity-Element.

Paketformat

Hier werden Einzelheiten von App-Paketen beschrieben, also das APPX-Dateiformat.

App-Pakete sind schreibgeschützt

Obwohl App-Pakete auf einer Teilmenge von OPC basieren, wird empfohlen, vorhandene APIs im Rahmen der Bearbeitung von App-Paketen nicht zum Ändern von OPC- oder ZIP-Dateien zu verwenden. Nachdem Sie ein App-Paket erstellt haben, sollte es als schreibgeschützt angesehen werden. Bei den Visual Studio- und MakeAppx-Prozessen, mit denen App-Pakete erstellt werden, wird die Datei AppxBlockMap.xml automatisch erstellt und dem Paket hinzugefügt. Wenn Sie den Paketinhalt ändern, müssen Sie entsprechend die Blockzuordnungsdatei des Pakets aktualisieren. Um ein neues Paket und eine neue Blockzuordnungsdatei zu erstellen, müssen Sie das Paket mit Visual Studio, mit dem Verpackungsbefehl von MakeAppx oder mit den IAppxPackageWriter-APIs von Windows 8 (systemeigener Code) neu erstellen.

Namen der Nutzlastdateien von App-Paketen

Zur Einhaltung der OPC-Richtlinien müssen die Dateipfadnamen aller Dateien, die in einem App-Paket gespeichert sind, URI-kompatibel (Uniform Resource Identifier) sein. Dateipfade, die nicht URI-kompatibel sind, müssen beim Speichern in einem App-Paket mit Prozentzeichen versehen werden und beim Extrahieren aus dem Paket zurück in den ursprünglichen Dateipfad decodiert werden. Angenommen, Sie verwenden eine Nutzlastdatei mit einem Pfad und Namen, der eingebettete Leerstellen und die für den URI reservierten Zeichen "[" und "]" enthält:


\my pictures\kids party[3].jpg

Wenn Sie diese Nutzlastdatei im App-Paket speichern, ergibt sich als Pfad der Datei Folgendes:


/my%20pictures/kids%20party%5B3%5D.jpg

Visual Studio, das App-Verpackungsprogramm (MakeAppx) und die Verpackungs-APIs führen die Codierung mit Prozentzeichen und das Decodieren der Dateipfade automatisch durch. Wenn Sie versuchen, Dateien mithilfe allgemeiner ZIP-Hilfsprogramme oder APIs direkt aus einem App-Paket zu extrahieren, bleibt die Codierung der Dateipfade mit Prozentzeichen unter Umständen erhalten. Daher wird empfohlen, Dateien entweder mithilfe des Entpackungsbefehls von MakeAppx oder mithilfe der IAppxPackageReader-APIs aus einem App-Paket zu extrahieren.

Kapazitäten von App-Paketen

Apps in App-Paketen werden bis zu den folgenden Kapazitätsgrenzen unterstützt:

PaketkapazitätMaximalwert
Dateianzahl100.000 Dateien
Paketgröße100 GB

 

Für App-Pakete reservierte Pfad- und Dateinamen

Die folgenden Pfad- und Dateinamen sind reserviert und sollten nicht für App-Nutzlastdateien verwendet werden:

Reservierte Pfad- und DateinamenVerwendung
/AppxManifest.xmlReservierter Dateiname für das vom Entwickler erstellte App-Paketmanifest
/AppxBlockMap.xmlReservierter Dateiname für die Blockzuordnung des App-Pakets
/AppxSignature.p7xReservierter Dateiname für die digitale Microsoft Authenticode-Signatur des App-Pakets
/[Content_Types].xmlReservierter Dateiname für Inhaltstypmetadaten, die OPC für das App-Paket erfordert
/AppxMetadata/Reservierter Ordnerpfad für Metadatendateien des App-Pakets
/Microsoft.System.Package.Metadata/Reservierter Ordnerpfad für Microsoft-Metadatendateien zu bereitgestellten App-Paketen

 

Digitale Signaturen von App-Paketen

Sie müssen die einzelnen App-Pakete signieren, bevor Benutzer sie installieren können. Das Signieren von App-Paketen ist zwar dank Authenticode teilweise automatisiert, Sie müssen jedoch die folgenden Features beim Signieren von App-Paketen steuern:

  • Der Antragstellername des Codesignaturzertifikats muss mit dem Publisher-Attribut übereinstimmen, das im Identity-Element der Datei AppxManifest.xml im App-Paket angegeben ist.
  • Der Hashalgorithmus, der zum Signieren des App-Pakets verwendet wird, muss mit dem Hashalgorithmus übereinstimmen, der zum Generieren der Datei AppxBlockMap.xml im App-Paket verwendet wird. Dieser Hashalgorithmus wird im HashMethod-Attribut des BlockMap-Elements angegeben.
  • Ein App-Paket kann nicht unabhängig von der Signierung mit einem Zeitstempel versehen werden. Wenn ein Zeitstempel erforderlich ist, muss dies während des Signiervorgangs erfolgen.
  • App-Pakete verfügen nicht über Unterstützung für mehrere verschachtelte Signaturen.

Anhand der Signatur eines Pakets wird bestimmt, wie die Windows-Runtime-App lizenziert wird. Die Art der Lizenzierung einer App wirkt sich darauf aus, wie die App installiert und ausgeführt werden kann. Daher kann es sein, dass zwei App-Pakete mit derselben Paketidentität bei der Installation nicht gleich behandelt werden. Beispielsweise können Sie kein App-Paket installieren, das über die gleiche Paketidentität wie eine bereits installierte App verfügt, wenn es nicht auch die gleiche Signatur aufweist.

Deklarative Installation

Die Bereitstellung der Windows-Runtime-App ist ein vollständig deklarativer Prozess, der auf dem App-Paketmanifest beruht. Im App-Paketmanifest definieren Sie die gewünschte Integration mit dem Betriebssystem. Beispielsweise deklarieren Sie mithilfe des App-Paketmanifests, dass für das Betriebssystem die Verwendung einer Dateitypzuordnung erforderlich ist, z. B. ".jpg".

Das Betriebssystem kann den Bereitstellungsprozess der Windows-Runtime-App dann vollständig verwalten, sodass jeder Benutzer auf jedem Gerät eine einheitliche und zuverlässige Funktionalität erhält. Aufgrund der deklarativen Installation der Windows-Runtime-App wird die Deinstallation der App außerdem zu einem deterministischen und wiederholbaren Vorgang.

Im App-Paketmanifest können Sie im Rahmen der Installation der Windows-Runtime-App viele verschiedene Technologien deklarieren.

Voraussetzungen für Apps

Zur erfolgreichen Bereitstellung einer App müssen für das Betriebssystem alle Voraussetzungen der App erfüllt sein, auf die im App-Paketmanifest verwiesen wird. Falls in einer Version des Betriebssystems z. B. eine neue API verfügbar gemacht wird, die von einer Windows-Runtime-App aufgerufen wird, deklariert die App eine Voraussetzung für die jeweilige Mindestversion des Betriebssystems. In diesem Fall muss auf dem Zielgerät das richtige Betriebssystem vorhanden sein, bevor die App installiert werden kann. Unter Windows 8 oder höher und Windows Phone 8.1 oder höher können Sie diese wichtigen Voraussetzungen im App-Paketmanifest deklarieren:

OSMinVersion

Gibt die für die Ausführung der App zulässige Mindestversion von Betriebssystem und App-Modellplattform an.

OSMaxVersionTested

Gibt die höchste Betriebssystemversion an, unter der die App vom Entwickler getestet und ihre Funktionsfähigkeit sichergestellt wurde. Mithilfe dieses Voraussetzungsfelds ermittelt das Betriebssystem, ob ein Problem mit der Kompatibilität der App vorliegt, das während der Nutzung der App auftreten kann. Wenn die App z. B. eine API aus dem Windows 8 SDK aufruft und die API in einer nachfolgenden Version des Betriebssystems geändert wurde, ist ein fehlerhaftes Verhalten der App möglich. Mit diesem Voraussetzungsfeld wird sichergestellt, dass das Betriebssystem dieses Verhalten identifizieren und korrigieren kann, damit die App unter allen nachfolgenden Versionen des Betriebssystems funktioniert.

Funktionen

Windows-Runtime-Apps, die programmgesteuerten Zugriff auf Benutzerressourcen wie Bilder oder auf verbundene Geräte wie eine Webcam benötigen, müssen die entsprechende Funktion deklarieren. Eine App fordert Zugriff an, indem sie Funktionen in ihrem App-Paketmanifest deklariert. Sie können Funktionen deklarieren, indem Sie den Manifest-Designer in Visual Studio verwenden, oder Sie können Funktionen dem Paketmanifest manuell hinzufügen, wie unter Angeben von Funktionen in einem Paketmanifest beschrieben. Weitere Informationen zu Funktionen finden Sie unter Deklaration der App-Funktionen.

Abhängigkeiten

Der Store hostet eine eindeutige Gruppe von App-Paketen, die unabhängig vom Betriebssystem arbeitende Betriebssystemkomponenten enthalten. Für Windows-Runtime-Apps können diese App-Pakete verwendet werden, indem in ihrem App-Paketmanifest eine Abhängigkeit deklariert wird. Diese Komponenten, die in den im Store gehosteten App-Paketen enthalten sind, werden als Betriebssystem-Komponentenbibliotheken bezeichnet. Der Store stellt durch einen Prozess sicher, dass die richtige Version der Komponentenbibliothek vorhanden ist, wenn die App auf einem Gerät installiert wird. Diese Bibliotheken, zu denen die Windows-Bibliothek für JavaScript, C++-Laufzeitbibliotheken (CRT) und PlayReady DRM gehören, sind für die Erstellung von Windows-Runtime-Apps von entscheidender Bedeutung. Wenn eine App aus dem Store bereitgestellt wird, erfüllt das Betriebssystem die Abhängigkeitsdeklaration, indem die entsprechende Komponentenbibliothek heruntergeladen und mit der aus dem Store heruntergeladenen App installiert wird.

  • Applies to Windows

Hinweis  Zum Querladen von Windows Store-Apps für Test- oder Unternehmensbereitstellungen muss das App-Paket mit der Windows-Komponentenbibliothek während der Bereitstellung des App-Pakets angegeben werden.

App-Bündel

Ab Windows 8.1 und Windows Phone 8.1 können Sie das App-Bündel (oder .appxbundle-Paket) verwenden, um die Verpackung und Verteilung einer Windows-Runtime-App und von Ressourcenpaketen für Benutzer in aller Welt zu optimieren.

Hinweis  Erstellen Sie ein App-Bündel für alle Architekturen statt separaten Bündeln für jede Architektur.

Sie erstellen für Ihre App die Nutzlast für das App-Bündel. Von Visual Studio wird das Bündelmanifest erstellt und hinzugefügt. Beim Erstellen des App-Bündels mit Visual Studio werden die Ressourcen automatisch auf separate Pakete aufgeteilt, und die App-Blockzuordnung und die Signaturdateien werden dem Bündel hinzugefügt. Diese Elemente bilden eine komplett eigenständige Windows-Runtime-App, die auf Systemen ab Windows 8.1 und Windows Phone 8.1 bereitgestellt werden kann.

App-Pakete (.appx)

Das App-Bündel kann nur dann mehrere App-Pakete enthalten, wenn diese jeweils für eine bestimmte Architektur bereitgestellt werden. Beispielsweise kann ein App-Bündel sowohl ein x86.appx-Paket als auch ein amd64.appx-Paket enthalten, jedoch nicht zwei amd64.appx-Pakete.

Ressourcenpakete (.appx)

Das App-Bündel enthält Ressourcenpakete (APPX-Dateien) für die Sprache, Skalierung und Microsoft DirectX-Featureebene. Jedes App-Bündel kann viele verschiedene Ressourcenpakete zur Unterstützung unterschiedlicher Gerätekonfigurationen enthalten. Bei dem direkten Verweis auf ein Ressourcenpaket in der Windows-Runtime-App sollten Sie das Ressourcenverwaltungssystem vollständig nutzen.

Hinweis  Ressourcenpakete dürfen nie Code enthalten.

App-Bündelmanifest (AppxBundleManifest.xml)

Das App-Bündelmanifest (Datei mit der Dateierweiterung ".appxbundlemanifest") enthält alle Informationen zur Anwendbarkeit der enthaltenen Pakete. Es gibt für jedes einzelne Paket die Art des Pakets ("Anwendung" oder "Ressource") sowie die Version und die Angabe zum Ressourcenziel an. Speziell für App-Pakete sind im App-Bündelmanifest Informationen über die Architektur enthalten.

Generell ermöglicht das App-Bündelmanifest dem App-Modell die Interpretation des Inhalts von App-Bündeln. Außerdem kann während der Installation ermittelt werden, welches App-Paket und welche Ressourcenpakete auf dem Gerät des Benutzers installiert werden müssen.

Dies ist ein Beispiel für ein App-Bündelmanifestdatei.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<Bundle xmlns="http://schemas.microsoft.com/appx/2013/bundle" SchemaVersion="1.0">
  <Identity Name="Example" Publisher="CN=ExamplePublisher" Version="2013.101.312.1053"/>
  <Packages>
    <Package Type="application" Version="1.0.0.5" Architecture="x86" FileName="AppPackage_X86.appx" Offset="49" Size="3207">
      <Resources>
        <Resource Language="en-us"/>
        <Resource Scale="100" />
      </Resources>
    </Package>
    <Package Type="application" Version="1.0.0.4" Architecture="x64" FileName="AppPackage_X64.appx" Offset="3329" Size="3204">
      <Resources>
        <Resource Language="en-us"/>
        <Resource Scale="100" />
      </Resources>
    </Package>
    <Package Type="resource" Version="1.0.0.0" ResourceId="French" FileName="ResourcePackage_French.appx" Offset="6606" Size="1423">
      <Resources>
        <Resource Language="fr"/>
        <Resource Language="fr-fr"/>
        <Resource Language="fr-ca"/>
      </Resources>
    </Package>
    <Package Type="resource" Version="1.0.0.3" ResourceId="HiRes" FileName="ResourcePackage_HiRes.appx" Offset="8111" Size="1584">
      <Resources>
        <Resource Scale="140"/>
      </Resources>
    </Package>
  </Packages>
</Bundle>

App-Blockzuordnung (AppxBlockMap.xml)

In der Blockzuordnungsdatei werden alle im Bündel (mit Ausnahme von App- und Ressourcenpaketen) enthaltenen Dateien zusammen mit den zugehörigen vom Betriebssystem für die Überprüfung der Dateiintegrität und zur Optimierung eines Updates für die App verwendeten kryptografischen Hashwerten aufgelistet. Weitere Informationen zur Blockzuordnungsdatei finden Sie unter Blockzuordnung des App-Pakets.

App-Signatur (AppxSignature.p7x)

Mit der Signatur des App-Bündels wird sichergestellt, dass das Paket und der Inhalt seit dem Signieren nicht mehr geändert wurden. Wenn die Überprüfung des Signaturzertifikats zu einem Zertifikat einer vertrauenswürdigen Stammzertifizierungsstelle führt, wird anhand der Signatur auch angegeben, wer das Paket signiert hat. Der Signaturgeber des Pakets ist normalerweise der Herausgeber oder Autor der App.

Ressourcenpakete

Ab Windows 8.1 und Windows Phone 8.1 können Sie mithilfe des Ressourcenpakets zusätzliche Ressourcen für die Kern-App bereitstellen (z. B. spezielle Zeichenfolgen- oder Bildressourcen für Französisch). Indem Sie das Ressourcenpaket verwenden, können Sie das Paket für die Kern-App von den zusätzlichen Ressourcen trennen. Das Ressourcenpaket stellt eine Verbesserung der Gesamtanpassung der App dar, ohne dass alle Ressourcenpakete auf das Gerät heruntergeladen und installiert werden müssen.

Das Ressourcenpaket ist optional, und das App-Paket darf nicht allein davon abhängig sein. Dies bedeutet, dass das App-Paket mindestens einen Satz mit Standardressourcen enthalten muss, die verwendet werden können, falls auf dem Gerät keine Ressourcenpakete installiert wurden. Damit können wichtige Zusagen eingehalten werden:

  • Das App-Paket kann auch auf Geräten ohne Ressourcenpakete immer installiert und gestartet werden.

  • Falls das installierte Ressourcenpaket nicht vollständig ist, sind für das App-Paket Ressourcen als Ersatz vorhanden.

Das Ressourcenpaket erfüllt im App-Modell die folgenden Aufgaben:

  • Bereitstellen von Ressourcenkandidaten, die vom Ressourcenverwaltungssystem während der Ausführung der App zum Anpassen der App-Oberfläche verwendet werden können.

  • Bereitstellen von Metadaten, mit denen das Ressourcenpaket auf einen bestimmten Ressourcenqualifizierer (z. B. Benutzersprache, Systemskalierung und DirectX-Features) ausgerichtet werden kann.

Ressourcenpakete können immer nur auf einen Ressourcenqualifizierer je Paket ausgerichtet werden. Ihre App kann jedoch über viele Ressourcenpakete verfügen.

Ressourcenpakete dürfen nie Code enthalten.

Feste Verknüpfung

Ab Windows 8.1 und Windows Phone 8.1 optimiert das Betriebssystem die Installation Ihrer App, indem das mehrfache Herunterladen derselben Datei nach Möglichkeit vermieden wird. Wenn das Betriebssystem erkennt, dass Ihre App eine Datei verwendet, die bereits zuvor auf dem Gerät installiert war, erstellt das Betriebssystem eine geteilte Version der Datei und weist Ihre App an, eine feste Verknüpfung mit der geteilten Version zu erstellen. Dies reduziert die Installationszeit und den Datenträgerbedarf der App. Bei diesen geteilten Dateien kann es sich um Bibliotheken, Runtimes usw. handeln. Wir empfehlen Ihnen die Verwendung bewährter Methoden, um feste Verknüpfungen optimal zu nutzen. Verwenden Sie für alle Versionen Ihrer App möglichst dieselben Runtime- oder Bibliotheks-Binärdateien, außer Sie müssen sie unbedingt aktualisieren.

  • Applies to Windows

Windows 8.1 Update:  Bei der ersten Veröffentlichung von Windows 8.1 waren feste Verknüpfungen auf Apps aus dem Windows Store beschränkt. Bei Windows 8.1 Update sind feste Verknüpfungen auch unter quergeladenen Unternehmens-Apps möglich. Weitere Informationen zum Querladen finden Sie unter Bereitstellen von Unternehmens-Apps.

Bereitstellungen pro Benutzer

  • Applies to Windows

Hinweis  

Die Bereitstellung von Windows-Runtime-Apps wird pro Benutzer durchgeführt. Dies bedeutet, dass nur das Konto des Benutzers betroffen ist, der die jeweilige App installiert hat. Bei Szenarien mit mehreren Benutzern wissen Benutzer auch nicht, was für andere Benutzer installiert wurde. Angenommen, Benutzer A hat die Editor-App installiert, und Benutzer B hat die Rechner-App installiert. Hierbei besitzen Benutzer A und Benutzer B keine Informationen zu anderen Apps, die auf dem Computer installiert sind (App-Isolation).

  • Applies to Windows

Hinweis  

Die App-Isolation ist auf dem Betriebssystem nur auf den Benutzerteil der Windows-Runtime-App beschränkt. Alle anderen Daten der App werden an einem Speicherort abgelegt, auf den das Betriebssystem zugreifen kann. Angenommen, Benutzer A hat die Rechner-App installiert, und Benutzer B hat ebenfalls die Rechner-App installiert. In diesem Fall wird nur eine Kopie von den Binärdateien der Rechner-App auf dem Laufwerk (%ProgramFiles%\WindowsApps), gespeichert, und beide Benutzer haben Zugriff darauf. Benutzer A sieht die App-Daten von Benutzer B nicht (und umgekehrt). Die Runtime-Binärdateien werden gemeinsam genutzt, aber die App-Daten sind isoliert.

Das Verzeichnis %Programme%\WindowsApp kann nicht geändert werden. Dies gilt auch für das zugrunde liegende Verzeichnis %ProgramFiles% und die Verzeichnisse %ProgramData% und %UserProfile%.

  • Applies to Windows

Hinweis  

Zusätzlich zu allen Binärdateien der Windows Store-Apps aller Benutzer des Systems kann das WindowsApps-Verzeichnis auch mehrere Versionen einer Windows Store-App enthalten. Angenommen, sowohl Benutzer A als auch Benutzer B hat die Editor-App installiert, und Benutzer A hat das Update auf Version 2 der Editor-App durchgeführt, Benutzer B jedoch nicht. In diesem Fall sind auf dem Betriebssystem zwei Versionen der Editor-App vorhanden. Da für jeden Benutzer nur eine Version installiert ist, tritt bei mehreren Versionen kein Konflikt auf.

Dieses Verhalten gilt auch für Abhängigkeitspakete.

Bereitstellung für Windows-Runtime-Apps

In diesen Abschnitten wird der Ablauf der Installation, Aktualisierung und Entfernung von Windows-Runtime-Apps beschrieben.

Installieren von Windows-Runtime-Apps

Die folgende Abbildung zeigt den Ablauf der Installation von Windows-Runtime-Apps:

Installationsablauf von Windows Store-Apps

Der Bereitstellungsprozess von Windows-Runtime-Apps umfasst mehrere Phasen. Zuerst ruft das Betriebssystem das App-Manifest, die App-Blockzuordnung und die App-Signatur ab und überprüft sie. Als Nächstes überprüft das Betriebssystem die Bereitstellungskriterien des App-Pakets, um sicherzustellen, dass die App-Bereitstellung erfolgreich ist. Danach stellt das Betriebssystem die Binärdateien des Pakets im Verzeichnis WindowsApps bereit. Zuletzt registriert das Betriebssystem das Paket für das Konto des Benutzers.

Bereitstellungschecks (Überprüfung)

Die folgende Abbildung zeigt die Phase, in der das Betriebssystem die Bereitstellungsüberprüfungen durchführt:

Checks bei der Installation von Bereitstellungen

Nachdem ein Benutzer die Installation einer Windows-Runtime-App gestartet hat, muss das Betriebssystem die folgenden Überprüfungen durchführen, bevor der Bereitstellungsprozess beginnen kann:

OSMinVersion wird verwendet

Sie geben die App-Voraussetzungen im Paketmanifest der App an. Damit wird die Anforderung beschrieben, dass eine bestimmte Mindestversion des Betriebssystems verwendet werden muss. Weitere Informationen zu App-Voraussetzungen finden Sie unter App-Voraussetzungen.

App-Abhängigkeiten werden berücksichtigt

Für Windows-Runtime-Apps kann eine Abhängigkeit von einem anderen App-Paket angegeben werden, um zusätzliche Funktionen zu nutzen, die für die App erforderlich sind. Weitere Informationen zu App-Abhängigkeiten finden Sie unter Abhängigkeiten.

Ausreichender Festplattenspeicher vorhanden

Jede Windows-Runtime-App erfordert für ihre Bereitstellung eine bestimmte Menge an Festplattenspeicher. Ist auf dem Gerät nicht genügend Speicherplatz zum Bereitstellen des Pakets vorhanden, tritt bei der Bereitstellung ein Fehler auf.

App wurde nicht bereits bereitgestellt

Im Kontext des jeweiligen Benutzers, der die Windows-Runtime-App installiert hat, kann die App nicht erneut installiert werden. Daher muss durch eine Überprüfung sichergestellt werden, dass die App nicht bereits installiert ist.

App-Ressourcen bestehen Signaturprüfung

Mithilfe der bereits überprüften BlockMap muss die Integrität jeder Datei des App-Pakets überprüft werden.

Paketbereitstellung (Staging)

Die folgende Abbildung zeigt die Phase, in der das Paket vom Betriebssystem bereitgestellt wird:

Bereitstellen des Pakets (Staging)

Nachdem das App-Modell ermittelt hat, dass das Paket auf dem Gerät bereitgestellt werden kann, speichert das Betriebssystem den Inhalt des Pakets auf dem Datenträger im Verzeichnis %ProgramFiles%\WindowsApps. Dafür wird ein neues Unterverzeichnis erstellt, das nach der Paketidentität benannt ist:


<Package Name>_<Version>_<Architecture>_<ResourceID>_<Publisher Hash>

Der Bereitstellungsprozess umfasst eine Reihe von Anforderungen, die vom Bereitstellungsmodul an die Quelle des Paketspeicherorts gestellt werden. Diese Anforderungen werden von der Quelle dann erfüllt und an das Bereitstellungsmodul zurückgegeben, wo sie dekomprimiert, anhand von BlockMap überprüft und in die entsprechende Datei kopiert werden.

Paketregistrierung

Die folgende Abbildung zeigt die Phase, in der das Paket vom Betriebssystem registriert wird:

Registrieren des Bereitstellungspakets

Die Registrierung des Pakets ist die letzte Phase des Bereitstellungsprozesses. Während dieser Phase werden die Erweiterungen, die im Manifest deklariert sind, beim Betriebssystem registriert. So wird ermöglicht, dass die App tief ins Betriebssystem integriert wird. Wenn Sie z. B. möchten, dass mit Ihrer App das Öffnen von TXT-Dateien möglich sein soll, deklarieren Sie im App-Paketmanifest eine FileTypeAssociation-Erweiterung im XML-Format und geben als Dateityp ".txt" an. Zur Bereitstellungszeit werden diese XML-Daten in die Gruppe der Systemänderungen übersetzt, die vorgenommen werden müssen, damit die App richtig für die Behandlung von TXT-Dateien registriert werden kann. Diese Änderungen werden vom App-Modell dann im Namen der App vorgenommen. Das App-Modell unterstützt viele unterschiedliche Erweiterungen. Weitere Informationen zu diesen Erweiterungen finden Sie unter App-Verträge und Erweiterungen.

Aktualisieren von Windows-Runtime-Apps

Die folgende Abbildung zeigt den Ablauf der Aktualisierung von Windows-Runtime-Apps:

Aktualisieren der Bereitstellung

Der Workflow zur Aktualisierung ähnelt dem Installieren von Windows-Runtime-Apps, es gibt aber einige wichtige Unterschiede.

Bereitstellungschecks bei der Aktualisierung

Die folgende Abbildung zeigt die Phase, in der das Betriebssystem die Bereitstellungsüberprüfungen durchführt:

Checks bei der Aktualisierung von Bereitstellungen

Wenn die Version des derzeit installierten App-Pakets größer oder gleich der Version ist, die der Benutzer installieren möchte, tritt bei der Bereitstellung ein Fehler auf.

Paketbereitstellung (Delta-Downloads)

Die folgende Abbildung zeigt die Phase, in der das Paket vom Betriebssystem aktualisiert wird:

Staging bei der Aktualisierung von Bereitstellungen

Der Staging-Prozess während einer Aktualisierung ähnelt dem normalen Staging-Prozess während der Installation. Der Hauptunterschied ist jedoch, dass eine vorhandene Version des Pakets bereits unter dem Betriebssystem installiert ist. Nachdem die Installation des vorhandenen Pakets abgeschlossen ist, wird eine Gruppe von Nutzlastdateien heruntergeladen und auf das Gerät kopiert. In vielen Fällen ändern sich die meisten Nutzlastdateien für die aktualisierte Version des App-Pakets nicht oder nur in geringem Maße. Sie können diese Nutzlastdateien verwenden, um den Inhalt und die Objekte des aktualisierten App-Pakets zu erstellen. Da die BlockMap-Struktur des App-Pakets eine Liste mit Hashes für jeden Block jeder Datei enthält, kann das Betriebssystem den genauen Änderungssatz auf Blockebene berechnen, indem die alten und neuen BlockMap-Dateien der App verglichen werden. Dieser Vergleich kann zu folgenden Ergebnissen führen:

Datei wurde nicht geändert

Die Datei verfügt über eine feste Verknüpfung mit dem Ordnerspeicherort des aktualisierten Pakets.

Blöcke in einer Datei wurden nicht geändert

Die unveränderten Blöcke werden in den Ordner des aktualisierten Pakets kopiert.

Blöcke in der Datei wurden geändert

Die geänderten Blöcke werden für das Herunterladen aus der Quelle gekennzeichnet.

Gesamte Datei ist neu

Die gesamte Datei wird aus der Quelle heruntergeladen.

Datei ist nicht mehr vorhanden

Die Datei wird nicht für die Aktualisierung verwendet.

Nach Abschluss des Vergleichs werden alle Daten, die beibehalten werden können, mit einer festen Verknüpfung versehen oder kopiert, und alle neuen Daten werden aus der Quelle heruntergeladen und zum Erstellen der aktualisierten Dateien verwendet.

Paketregistrierung für die Aktualisierung

Die folgende Abbildung zeigt die Phase, in der das aktualisierte Paket vom Betriebssystem registriert wird:

Registrieren des aktualisierten Bereitstellungspakets

Wenn Sie die Registrierung eines Pakets aktualisieren, muss das Betriebssystem auch die Registrierungen der vorherigen Versionen aktualisieren. Das App-Modell aktualisiert automatisch alle vorhandenen Erweiterungsregistrierungen, entfernt veraltete Registrierungen und registriert neue Erweiterungen basierend auf den Deklarationen, die in den Manifesten der alten und neuen Versionen der App enthalten sind.

In Verwendung befindliche Apps

Der Prozess zur Aufhebung der Registrierung für ein App-Paket im Betriebssystem umfasst auch das Entfernen der internen Daten, die dem Betriebssystem das Starten der Windows-Runtime-App ermöglichen. In bestimmten Fällen kann die App während der Aktualisierung auch ausgeführt werden. Dabei fordert das Bereitstellungsmodul das Anhalten und dann das Beenden der App an. Je nach Ergebnis dieser Anforderung ist der Aktualisierungsprozess entweder erfolgreich oder nicht erfolgreich. Falls die Vorgänge erfolgreich durchgeführt werden können, wird für die App auch das Starten verhindert. Dies gilt für den kurzen Zeitraum, in dem das neue App-Paket registriert und die Registrierung des alten App-Pakets aufgehoben wird. Nach Abschluss dieser Phase kann die App wieder gestartet werden.

App-Daten

App-Daten sind eine Entität mit einer Version, die außerhalb der eigentlichen Windows-Runtime-App liegt. Wenn das ApplicationData.Version-Element nicht während des Updates der Windows-Runtime-App aktualisiert wurde, wirkt sich das Update für die Windows-Runtime-App nicht auf den App-Status aus.

Aufheben der Bereitstellung des Pakets (De-Staging)

Die folgende Abbildung zeigt die Phase, in der die Bereitstellung des aktualisierten Pakets vom Betriebssystem aufgehoben wird:

Aufheben der Registrierung des aktualisierten Bereitstellungspakets

Nach dem erfolgreichen Abschluss des Registrierungsvorgangs wird das Paket, sofern die vorhandene Version des Pakets nicht von einem anderen Benutzer des Betriebssystems verwendet wird, für die Entfernung aus dem Betriebssystem markiert. Zuerst kopiert das Betriebssystem den App-Paketordner der vorhandenen Version in das Verzeichnis %ProgramFiles%\WindowsApps\Deleted. Falls keine anderen Bereitstellungsvorgänge aktiv sind, löscht das Betriebssystem den App-Paketordner der vorhandenen Version.

  • Applies to Windows

Hinweis  Bei Szenarien mit mehreren Benutzern kann es sein, dass das App-Paket unter dem Betriebssystem für andere Benutzer weiterhin installiert ist. In diesem Fall wird die Bereitstellung des Paketinhalts im Betriebssystem erst aufgehoben, wenn alle Benutzer das Paket entfernt haben.

Entfernen von Windows-Runtime-Apps

Die folgende Abbildung zeigt den Ablauf der Entfernung von Windows-Runtime-Apps:

Entfernen der Bereitstellung

  • Applies to Windows

Hinweis  Da Pakete auf einem Computer pro Benutzer installiert werden, werden sie auch pro Benutzer entfernt. Wenn die Windows Store-App für mehrere Benutzer installiert wird, wird die Registrierung nur für den aktuellen Benutzer aufgehoben. Wenn Benutzer A und Benutzer B jeweils die Rechner-App installiert haben und Benutzer A die App deinstalliert, wird diese nur für Benutzer A entfernt, nicht für Benutzer B. Der Entfernungsprozess umfasst die gleichen grundlegenden Phasen wie der Prozess der Aktualisierung.

Aufheben der Registrierung des Pakets

Die folgende Abbildung zeigt die Phase, in der die Registrierung des entfernten Pakets vom Betriebssystem aufgehoben wird:

Aufheben der Registrierung des entfernten Bereitstellungspakets

Beim Aufheben der Registrierung wird die Integration der Windows-Runtime-App in das Konto des Benutzers entfernt. Außerdem werden alle zugeordneten Daten, die unter dem Konto des Benutzers installiert wurden (z. B. der App-Status), entfernt. Ähnlich wie beim Prozess der Aktualisierung muss das Bereitstellungsmodul über den Process Lifetime Manager (PLM) anfordern, dass die App angehalten und beendet wird, damit die Registrierung der App im Konto des Benutzers aufgehoben werden kann.

Hinweis  Nach der PLM-Rückgabe wird das Aufheben der Registrierung der Windows-Runtime-App für das Konto des Benutzers fortgesetzt. Der Entfernungsvorgang wird auch fortgesetzt, wenn PLM nicht erfolgreich war.

Aufheben der Bereitstellung des Pakets (De-Staging)

Die folgende Abbildung zeigt die Phase, in der die Bereitstellung des entfernten Pakets vom Betriebssystem aufgehoben wird:

Aufheben der Bereitstellung des entfernten Bereitstellungspakets

Nach dem erfolgreichen Abschluss der Registrierungsaufhebung wird das Paket, sofern es nicht von einem anderen Benutzer des Betriebssystems verwendet wird, für die Entfernung aus dem Betriebssystem markiert. Zuerst kopiert das Betriebssystem den App-Paketordner des Pakets in das Verzeichnis %ProgramFiles%\WindowsApps\Deleted. Falls keine anderen Bereitstellungsvorgänge aktiv sind, löscht das Betriebssystem den App-Paketordner des Pakets.

  • Applies to Windows

Hinweis  

Bei Szenarien mit mehreren Benutzern kann es sein, dass das App-Paket unter dem Betriebssystem für andere Benutzer weiterhin installiert ist. In diesem Fall wird die Bereitstellung des Paketinhalts im Betriebssystem erst aufgehoben, wenn alle Benutzer das Paket entfernt haben.

Bereitstellung von App-Bündeln

Ab Windows 8.1 und Windows Phone 8.1 können Sie App-Bündel bereitstellen, um die Verpackung und Verteilung einer App zu optimieren.

Die Bereitstellung von App-Bündeln über den Store erfolgt nach dem unten beschriebenen Workflow.

Workflow der App-Verpackung

Der Bereitstellungsprozess von Windows-Runtime-Apps umfasst mehrere Phasen. Zuerst ruft das Betriebssystem das App-Bündelmanifest, die Blockzuordnung und die Signatur des Bündels ab und überprüft sie. Als Nächstes überprüft das Betriebssystem das Bündelmanifest, um sicherzustellen, dass eine App vorhanden ist, die unter der aktuellen Architektur bereitgestellt werden kann. Wenn das richtige App-Paket gefunden wurde, überprüft das Betriebssystem die Bereitstellungskriterien des App-Pakets, um sicherzustellen, dass die App-Bereitstellung erfolgreich ist.

Danach ermittelt das Betriebssystem die Teilmenge der für die Bereitstellung anwendbaren Ressourcenpakete und stellt die Binärdateien des Pakets im Verzeichnis \WindowsApps\ bereit. Im letzten Schritt registriert das Betriebssystem das App-Paket und die Ressourcenpakete für das Konto des Benutzers.

Überprüfung

Nachdem ein Benutzer die Installation einer Windows-Runtime-App gestartet hat, muss das Betriebssystem die folgenden Überprüfungen durchführen, bevor die Bereitstellung beginnen kann.

TestBedingungen

Unterstützung der Architektur

Das Bündel kann bis zu drei Architektur-spezifische App-Pakete enthalten, die alle im App-Bündelmanifest angegeben sind.

Mindestversion des Betriebssystems

Sie geben die Voraussetzungen im Paketmanifest der App an. Damit wird die Anforderung beschrieben, dass eine bestimmte Mindestversion des Betriebssystems verwendet werden muss. Zum Beispiel lautet für Windows 8.1 die entsprechende Versionsnummer 6.3. Weitere Informationen zu App-Voraussetzungen finden Sie unter Voraussetzungen beim Verpacken von Apps.

App-Abhängigkeiten

Für eine Windows-Runtime-App kann eine Abhängigkeit von einem anderen Komponentenpaket angegeben werden, um zusätzliche Funktionen zu nutzen, die für die App erforderlich sind. Weitere Informationen zu App-Abhängigkeiten finden Sie unter Abhängigkeiten beim Verpacken von Apps.

Festplattenspeicher

Für jede Windows-Runtime-App ist eine bestimmte Menge an Speicherplatz für die Bereitstellung erforderlich. Ist nicht genügend Speicherplatz zum Bereitstellen des Pakets vorhanden, tritt bei der Bereitstellung ein Fehler auf.

Signaturprüfung

Bei jeder Datei im App-Paket muss die Dateiintegrität gegenüber der bereits überprüften BlockMap geprüft werden.

 

Anwendbarkeit des Pakets

Nachdem das Betriebssystem festgestellt hat, dass das App-Bündel auf dem System bereitgestellt werden kann, ermittelt es, welche Ressourcenpakete zusätzlich zum App-Paket bereitgestellt werden sollen, um die Benutzerfreundlichkeit der App zu erhöhen. Die Anwendbarkeit wird basierend auf den folgenden drei Ressourcenqualifizierer überprüft.

QualifiziererBeschreibung

Benutzersprache

Alle Sprachen, die der Benutzer zur Liste der bevorzugten Sprachen hinzugefügt hat, werden zur endgültigen Gruppe der anwendbaren Sprachressourcenpakete hinzugezählt, die bereitgestellt werden sollen. Windows 8.1 oder höher und Windows Phone 8.1 oder höher unterstützen viele Gebietsschemas und Sprachen für Ressourcenpakete.

Systemskalierung

Skalierungswerte für alle Monitore werden verwendet, um die endgültige Gruppe der anwendbaren Skalierungsressourcenpakete zu ermitteln, die bereitgestellt werden sollen. Für Windows 8.1 oder höher und Windows Phone 8.1 oder höher empfehlen wir die folgenden Skalierungsfaktoren für Ressourcenpakete:

Windows 8.1 und höher:  scale-100, scale-140 und scale-180

Windows Phone 8.1 und höher:  scale-100, scale-140 und scale-240

DirectX-Featureebene

Alle im System verfügbaren DirectX-Featureebenen werden verwendet, um die endgültige Gruppe der anwendbaren DirectX-Ressourcenpakete zu ermitteln, die bereitgestellt werden sollen. Windows 8.1 oder höher und Windows Phone 8.1 oder höher unterstützen drei DirectX-Featureebenen für Ressourcenpakete: DXFL-DX9, DXFL-DX10 und DXFL-DX11.

 

Paketbereitstellung (Staging)

Nachdem das Betriebssystem festgestellt hat, dass das App-Bündel auf dem System bereitgestellt werden kann und welche Pakete bereitzustellen sind, werden die Paketinhalte in das Verzeichnis \WindowsApps\ heruntergeladen. Für jedes heruntergeladene Paket wird ein neues Verzeichnis erstellt, das nach dem Paketidentitätsnamen (Wert) benannt ist.

<Package Name>_<Version>_<Architecture>_<ResourceID>_<Publisher Hash>

Der Bereitstellungsprozess umfasst eine Reihe von Anforderungen, die vom Bereitstellungsmodul an die Quelle des Paketspeicherorts gestellt werden. Diese Anforderungen werden von der Quelle dann erfüllt und an das Bereitstellungsmodul zurückgegeben, wo sie dekomprimiert, anhand von BlockMap überprüft und in die entsprechende Datei kopiert werden.

Paketregistrierung

Die Registrierung des Pakets ist die letzte Phase des Bereitstellungsprozesses. Während dieser Phase werden zwei wichtige Vorgänge ausgeführt:

  • Die Erweiterungen, die im Paketmanifest der App deklariert sind, werden beim Betriebssystem registriert. Dadurch wird die App tief in das Betriebssystem integriert. Wenn Sie z. B. möchten, dass mit Ihrer App das Öffnen von TXT-Dateien möglich sein soll, deklarieren Sie im Paketmanifest Ihrer App eine FileTypeAssociation-Erweiterung im XML-Format und geben als Dateityp ".txt" an.

    Zur Bereitstellungszeit werden diese XML-Daten in die Gruppe der Systemänderungen übersetzt, die erforderlich sind, damit die App richtig für die Behandlung von TXT-Dateien registriert werden kann. Diese Änderungen werden dann vom App-Modell im Auftrag der App durchgeführt. Das App-Modell unterstützt viele unterschiedliche Erweiterungen. Weitere Informationen zu diesen Erweiterungen finden Sie unter App-Verträge und Erweiterungen.

  • Alle Ressourcenpakete werden bei dem Ressourcenverwaltungssystem registriert. Dieses System verwendet dann die Ressourcenpakete, um die App-Oberfläche während der App-Ausführung optimal an den Benutzer anzupassen.

Paketinventar

Beim Installieren, Aktualisieren und Entfernen von Windows-Runtime-Apps können Benutzer jederzeit anzeigen, welche App-Pakete installiert oder vorab bereitgestellt werden.

  • Applies to Windows

Hinweis  Benutzer mit Administratorrechten können auch für alle Benutzer des Systems anzeigen, welche App-Pakete installiert sind. Weitere Informationen zum Inventarisieren von Paketen auf dem Betriebssystem finden Sie unter Tools und PowerShell-Cmdlets.

Häufig gestellte Fragen

Wie installiere ich mehrere Pakete gleichzeitig?

Sie können mehrere Pakete installieren, indem Sie die Verpackungs-APIs mehrfach oder einmal für den gesamten zu installierenden Paketsatz aufrufen. Die zugrunde liegende Implementierung des App-Modells ermöglicht, dass sich eine beliebige Anzahl von App-Paketen im Wartezustand für die Bereitstellung befinden kann. Es sind jedoch nur maximal drei gleichzeitige Bereitstellungsvorgänge (Staging) pro Benutzer (insgesamt sieben gleichzeitige Bereitstellungsvorgänge pro Betriebssystem) und ein Registrierungsvorgang pro Betriebssystem zulässig.

Was passiert, wenn das Paket bereits installiert ist?

Wenn ein Paket bereits installiert ist, ist schon ein Paket mit der gleichen Paketidentität vorhanden, die für das Konto des aktuellen Benutzers registriert ist. Das identische Paket wird in diesem Fall nicht installiert.

Kann ein Update obligatorisch gemacht werden?

Es ist nicht möglich, eine Aktualisierung per App-Modell obligatorisch zu machen. Das Aktualisierungsmodell ist stets optional. In Ausnahmefällen kann es vorkommen, dass ein Update vom Store als ungeeignet für die Verteilung als Update mit höherer Priorität eingestuft wird (z. B. ein Sicherheitsfix). Ist dies der Fall, kann die Verteilung des Updates an die Clients erzwungen werden.

  • Applies to Windows

Hinweis  

In einem Unternehmen kann ein Update per Gruppenrichtlinie erzwungen werden.

Wie kann ich für ein Update ein Rollback auf eine vorherige Version durchführen?

Es ist nicht möglich, für eine Windows-Runtime-App ein Rollback auf eine vorherige Version der App vorzunehmen. Da die Daten des App-Pakets kurz nach der Deinstallation des Pakets aus dem Betriebssystem entfernt werden, ist eine Wiederherstellung ausgeschlossen.

Kann ich die Verzeichnisse %Programme%, %ProgramData% oder %UserProfile% anders anordnen?

Dieses Szenario wird für Windows-Runtime-Apps nicht unterstützt und führt zu Fehlern bei der Verwendung der App.

Programmierschnittstellen für das Packen und Bereitstellen

Windows-Runtime

Win32/COM

 

 

Anzeigen:
© 2015 Microsoft