Freigeben über

In-App-Käufe und Testversionen

  • Artikel

Das Windows SDK bietet APIs, mit denen Sie die folgenden Features implementieren können, um mehr Geld mit Ihrer UWP-App (Universelle Windows-Plattform) zu verdienen:

  • In-App-Käufe Unabhängig davon, ob Ihre App kostenlos oder kostenpflichtig ist, können Sie Inhalte oder neue App-Funktionen (wie das Freischalten des nächsten Levels eines Spiels) direkt in der App verkaufen.

  • Testfunktionen Wenn Sie Ihre App als kostenlose Testversion in Partner Center konfigurieren, können Sie Ihre Kund*innen möglicherweise dazu bewegen, die Vollversion Ihrer App zu erwerben, indem Sie einige Features während des Testzeitraums ausschließen oder einschränken. Sie können auch Features wie Banner oder Wasserzeichen aktivieren, die in der Testversion angezeigt werden, bis Kund*innen Ihre App kaufen.

Dieser Artikel enthält eine Übersicht über die Funktionsweise von In-App-Käufen und Testversionen in UWP-Apps.

Auswählen des zu verwendenden Namespace

Es stehen zwei verschiedene Namespaces zur Verfügung, die Sie verwenden können, um Ihren UWP-Apps In-App-Käufe und Testversionen hinzuzufügen – je nachdem, auf welche Version von Windows 10 oder Windows 11 Ihre App ausgelegt ist. Die APIs in diesen Namespaces dienen zwar dem gleichen Zweck, sind jedoch unterschiedlich konzipiert, und zwischen den beiden APIs besteht keine Codekompatibilität.

  • Windows.Services.Store Ab Windows 10 Version 1607 können mithilfe der API in diesem Namespace In-App-Käufe und Testversionen in Apps implementiert werden. Es empfiehlt sich, die Member in diesem Namespace zu verwenden, wenn Ihr App-Projekt auf Windows 10 Anniversary Edition (10.0, Build 14393) oder auf ein höheres Release in Visual Studio ausgerichtet ist. Dieser Namespace unterstützt die neuesten Add-On-Typen (z. B. vom Store verwaltete verbrauchsbasierte Add-Ons) und ist so gestaltet, dass er mit zukünftigen Arten von Produkten und Features kompatibel ist, die von Partner Center und vom Store unterstützt werden. Weitere Informationen zu diesem Namespace finden Sie in diesem Artikel im Abschnitt In-App-Käufe und Testversionen mit dem Namespace „Windows.Services.Store“.

  • Windows.ApplicationModel.Store In diesem Namespace unterstützen alle Versionen von Windows 10 und Windows 11 auch eine ältere API für In-App-Käufe und Testversionen. Informationen zum Namespace Windows.ApplicationModel.Store finden Sie unter In-App-Käufe und Testversionen mit dem Namespace „Windows.ApplicationModel.Store“.

Wichtig

Der Namespace Windows.ApplicationModel.Store wird nicht mehr mit neuen Features aktualisiert, und es wird empfohlen, stattdessen den Namespace Windows.Services.Store für Ihre App zu verwenden, sofern möglich. Der Namespace Windows.ApplicationModel.Store wird in Windows-Desktopanwendungen, die die Desktop-Brücke nutzen, sowie in Apps oder Spielen, die eine Entwicklungs-Sandbox in Partner Center verwenden (was beispielsweise bei allen Spielen der Fall ist, die in Xbox Live integriert sind), nicht unterstützt.

Grundlegende Konzepte

Jedes im Store angebotene Element wird allgemein als Produkt bezeichnet. Die meisten Entwickler*innen arbeiten nur mit folgenden Produkttypen: Apps und Add-Ons.

Ein Add-On ist ein Produkt oder Feature, das Sie Ihren Kund*innen im Kontext Ihrer App zur Verfügung stellen. Hierzu zählen beispielsweise eine App- oder spielspezifische Währung, neue Karten oder Waffen für ein Spiel, die Möglichkeit zur Verwendung der App ohne Werbung oder digitale Inhalte wie Musik oder Videos für Apps, die diese Art von Inhalten anbieten können. Alle Apps und Add-Ons verfügen jeweils über eine zugehörige Lizenz, die angibt, ob Benutzer*innen berechtigt sind, die App oder das Add-On zu verwenden. Wenn Benutzer*innen berechtigt sind, die App oder das Add-On als Testversion zu verwenden, enthält die Lizenz auch zusätzliche Informationen zur Testversion.

Wenn Sie Kund*innen in Ihrer App ein Add-On anbieten möchten, müssen Sie das Add-On für Ihre App in Partner Center definieren, damit der Store darüber informiert ist. Anschließend kann Ihre App APIs im Namespace Windows.Services.Store oder Windows.ApplicationModel.Store verwenden, um Benutzer*innen das Add-On als In-App-Kauf anzubieten.

Von UWP-Apps können folgende Arten von Add-Ons angeboten werden:

Add-On-Typ Beschreibung
Durable Ein Add-On, das für die in Partner Center angegebene Lebensdauer bestehen bleibt.

Standardmäßig laufen langlebige Add-Ons nie ab. In diesem Fall können sie nur einmal erworben werden. Wenn Sie eine bestimmte Dauer für das Add-On angeben, können Benutzer*innen das Add-On nach dem Ablauf erneut erwerben.
Entwicklerseitig verwalteter Verbrauchsartikel Ein Add-On, das gekauft, verwendet und nach dem Verbrauch erneut gekauft werden kann. Sie sind dafür verantwortlich, den Saldo der Elemente von Benutzer*innen nachzuverfolgen, den das Add-On darstellt.

Wenn Benutzer*innen Elemente verbrauchen, die dem Add-On zugeordnet sind, sind Sie dafür verantwortlich, den Saldo der Benutzer*innen zu pflegen und den Kauf des Add-Ons als erfüllt an den Store zu melden, nachdem Benutzer*innen alle Elemente verbraucht haben. Benutzer*innen können das Add-On erst dann erneut kaufen, wenn die App den vorherigen Add-On-Kauf als erfüllt gemeldet hat.

Ein Beispiel: Wenn Ihr Add-On 100 Münzen in einem Spiel darstellt und Benutzer*innen zehn Münzen verbrauchen, muss Ihre App oder Ihr Dienst den neuen Saldo von 90 Münzen für die Benutzer*innen speichern. Wenn Benutzer*innen alle 100 Münzen verbraucht haben, muss Ihre App das Add-On als erfüllt melden, und die Benutzer*innen können das Add-On mit den 100 Münzen erneut kaufen.
Vom Store verwalteter Verbrauchsartikel Ein Add-On, das erworben, verwendet und jederzeit erneut erworben werden kann. Der Saldo der Elemente von Benutzer*innen, den das Add-On darstellt, wird vom Store nachverfolgt.

Wenn Benutzer*innen Elemente verbrauchen, die dem Add-On zugeordnet sind, sind Sie dafür verantwortlich, diese Elemente dem Store als erfüllt zu melden, und der Store aktualisiert den Saldo der Benutzer*innen. Benutzer*innen können das Add-On beliebig oft kaufen (ohne die Elemente zuvor zu verbrauchen). Ihre App kann den aktuellen Saldo für die Benutzer*innen jederzeit abfragen.

Wenn das Add-On beispielsweise eine anfängliche Menge von 100 Münzen in einem Spiel darstellt und Benutzer*innen 50 Münzen verbrauchen, meldet die App dem Store, dass 50 Einheiten des Add-Ons erfüllt wurden, und der Store aktualisiert den Restsaldo. Wenn Benutzer*innen Ihr Add-On nun erneut kaufen, um weitere 100 Münzen zu erwerben, verfügen sie über insgesamt 150 Münzen.

Hinweis Um vom Store verwaltete Verbrauchsartikel verwenden zu können, muss Ihre App auf Windows 10 Anniversary Edition (10.0, Build 14393) oder auf ein höheres Release in Visual Studio ausgerichtet sein, und anstelle des Namespace Windows.ApplicationModel.Store muss der Namespace Windows.Services.Store verwendet werden.
Subscription Ein langlebiges Add-On, bei dem Kund*innen in regelmäßigen Abständen eine Gebühr in Rechnung gestellt wird, um das Add-On weiter verwenden zu können. Kund*innen können das Abonnement jederzeit kündigen, um weitere Gebühren zu vermeiden.

Hinweis Um abonnementbasierte Add-Ons verwenden zu können, muss Ihre App auf Windows 10 Anniversary Edition (10.0, Build 14393) oder auf ein höheres Release in Visual Studio ausgerichtet sein, und anstelle des Namespace Windows.ApplicationModel.Store muss der Namespace Windows.Services.Store verwendet werden.

Hinweis

Andere Arten von Add-Ons wie langlebige Add-Ons mit Paketen (auch herunterladbare Inhalte oder DLCs genannt) stehen nur einer eingeschränkten Gruppe von Entwickler*innen zur Verfügung und werden in dieser Dokumentation nicht behandelt.

In-App-Käufe und Testversionen mit dem Namespace „Windows.Services.Store“

Dieser Abschnitt enthält eine Übersicht über wichtige Aufgaben und Konzepte für den Namespace Windows.Services.Store. Dieser Namespace ist nur für Apps verfügbar, die auf Windows 10 Anniversary Edition (10.0, Build 14393) oder auf ein höheres Release in Visual Studio (entspricht Windows 10, Version 1607) ausgerichtet sind. Apps sollten nach Möglichkeit den Namespace Windows.Services.Store und nicht den Namespace Windows.ApplicationModel.Store verwenden. Weitere Informationen zum Namespace Windows.ApplicationModel.Store finden Sie in diesem Artikel.

In diesem Abschnitt

Erste Schritte mit der Klasse „StoreContext“

Der Haupteinstiegspunkt für den Namespace Windows.Services.Store ist die Klasse StoreContext. Diese Klasse stellt Methoden bereit, mit denen Sie Informationen für die aktuelle App und die verfügbaren Add-Ons sowie Lizenzinformationen für die aktuelle App oder die Add-Ons abrufen, eine App oder ein Add-On für den aktuellen Benutzer bzw. für die aktuelle Benutzerin kaufen und weitere Aufgaben ausführen können. Führen Sie zum Abrufen eines Objekts vom Typ StoreContext eine der folgenden Aktionen aus:

  • Rufen Sie in einer Einzelbenutzer-App (eine App, die nur im Kontext des Benutzers bzw. der Benutzerin ausgeführt wird, der bzw. die die App gestartet hat) mithilfe der statischen Methode GetDefault ein Objekt vom Typ StoreContext ab, mit dem Sie auf Microsoft Store-bezogene Daten für den Benutzer bzw. für die Benutzerin zugreifen können. Die meisten UWP-Apps (Universelle Windows-Plattform) sind Einzelbenutzer-Apps.

    Windows.Services.Store.StoreContext context = StoreContext.GetDefault();

  • Verwenden Sie in einer Mehrbenutzer-App die statische Methode GetForUser, um ein Objekt vom Typ StoreContext abzurufen, mit dem Sie für einen bestimmten Benutzer bzw. für eine bestimmte Benutzerin, der bzw. die bei der Verwendung der App mit seinem bzw. ihrem Microsoft-Konto angemeldet ist, auf Microsoft Store-bezogene Daten zugreifen können. Im folgenden Beispiel wird ein Objekt vom Typ StoreContext für den ersten verfügbaren Benutzer bzw. für die erste verfügbare Benutzerin abgerufen.

    var users = await Windows.System.User.FindAllAsync();
Windows.Services.Store.StoreContext context = StoreContext.GetForUser(users[0]);

Hinweis

Bei Windows-Desktopanwendungen, die die Desktop-Brücke verwenden, müssen zum Konfigurieren des Objekts StoreContext zusätzliche Schritte ausgeführt werden, damit es verwendet werden kann. Weitere Informationen finden Sie in diesem Abschnitt.

Wenn Sie dann über ein Objekt vom Typ StoreContext verfügen, können Sie Methoden dieses Objekts aufrufen, um Store-Produktinformationen für die aktuelle App und deren Add-Ons zu erhalten, Lizenzinformationen für die aktuelle App und ihre Add-Ons abzurufen, eine App oder ein Add-On für den aktuellen Benutzer bzw. für die aktuelle Benutzerin zu erwerben und andere Aufgaben auszuführen. Weitere Informationen zu allgemeinen Aufgaben, die Sie mit diesem Objekt ausführen können, finden Sie in den folgenden Artikeln:

Eine Beispiel-App, die veranschaulicht, wie StoreContext und andere Typen im Namespace Windows.Services.Store verwendet werden, finden Sie im Store-Beispiel.

Implementieren von In-App-Käufen

So bieten Sie Kund*innen in Ihrer App einen In-App-Kauf unter Verwendung des Namespace Windows.Services.Store an

  1. Wenn Ihre App über Add-Ons verfügt, die von Kund*innen gekauft werden können, erstellen Sie Add-On-Übermittlungen für Ihre App in Partner Center.

  2. Schreiben Sie in Ihrer App Code zum Abrufen von Produktinformationen für Ihre App oder für ein von Ihrer App angebotenes Add-On, und ermitteln Sie dann, ob die Lizenz aktiv ist (also ob der Benutzer bzw. die Benutzerin über eine Lizenz für die Verwendung der App oder des Add-Ons verfügt). Ist die Lizenz nicht aktiv, zeigen Sie eine Benutzeroberfläche an, auf der die App oder das Add-On als In-App-Kauf angeboten wird.

  3. Wenn Benutzer*innen Ihre App oder Ihr Add-On kaufen möchten, verwenden Sie die passende Kaufmethode für das Produkt:

  4. Testen Sie Ihre Implementierung wie in diesem Artikel beschrieben.

Implementieren von Testfunktionen

So können Sie Features in einer Testversion Ihrer App unter Verwendung des Namespace Windows.Services.Store ausschließen oder einschränken

  1. Konfigurieren Sie Ihre App als kostenlose Testversion in Partner Center.

  2. Schreiben Sie in Ihrer App Code zum Abrufen von Produktinformationen für Ihre App oder für ein von Ihrer App angebotenes Add-On, und ermitteln Sie dann, ob die der App zugeordnete Lizenz eine Testlizenz ist.

  3. Schließen Sie bestimmte Features in Ihrer App aus, oder schränken Sie sie ein, wenn es sich um eine Testversion handelt, und aktivieren Sie die Features, wenn Benutzer*innen eine Lizenz für die Vollversion erwerben. Weitere Informationen und ein Codebeispiel finden Sie unter Implementieren einer Testversion der App.

  4. Testen Sie Ihre Implementierung wie in diesem Artikel beschrieben.

Testen Ihrer Implementierung von In-App-Käufen oder Testversionen

Wenn Ihre App APIs im Namespace Windows.Services.Store verwendet, um In-App-Käufe oder Testfunktionen zu implementieren, müssen Sie Ihre App im Store veröffentlichen und auf Ihr Entwicklungsgerät herunterladen, um die zugehörige Lizenz zu Testzwecken zu verwenden. Gehen Sie zum Testen Ihres Codes wie folgt vor:

  1. Falls Ihre App noch nicht im Store veröffentlicht und verfügbar gemacht wurde, stellen Sie sicher, dass Ihre App die Mindestanforderungen des Zertifizierungskits für Windows-Apps erfüllt, übermitteln Sie Ihre App in Partner Center, und stellen Sie sicher, dass sie den Zertifizierungsprozess besteht. Während der Testphase können Sie Ihre App so konfigurieren, dass sie nicht im Store auffindbar ist. Beachten Sie die korrekte Konfiguration von Flight-Paketen. Falsch konfigurierte Flight-Pakete können möglicherweise nicht heruntergeladen werden.

  2. Vergewissern Sie sich als Nächstes, dass folgende Schritte abgeschlossen sind:

  3. Vergewissern Sie sich in Visual Studio, dass Ihr Projekt geöffnet ist, klicken Sie auf das Menü Projekt, zeigen Sie auf Store, und klicken Sie dann auf App mit Store verknüpfen. Befolgen Sie die Anweisungen des Assistenten, um das App-Projekt mit der App in Ihrem Partner Center-Konto zu verknüpfen, die Sie zum Testen verwenden möchten.

    Hinweis

    Wenn Sie das Projekt nicht mit einer App im Store verknüpfen, legen die Methoden vom Typ StoreContext die Eigenschaft ExtendedError ihrer Rückgabewerte auf den Fehlercodewert 0x803F6107 fest. Dieser Wert gibt an, dass die App im Store nicht bekannt ist.

  4. Falls noch nicht geschehen, installieren Sie die im vorherigen Schritt angegebene App aus dem Store, führen Sie sie einmal aus, und schließen Sie sie dann. Dadurch wird sichergestellt, dass auf Ihrem Entwicklungsgerät eine gültige Lizenz für die App installiert ist.

  5. Beginnen Sie in Visual Studio damit, Ihr Projekt auszuführen oder zu debuggen. Ihr Code sollte App- und Add-On-Daten von der Store-App abrufen, die Sie mit Ihrem lokalen Projekt verknüpft haben. Wenn Sie aufgefordert werden, die App neu zu installieren, folgen Sie den Anweisungen, und führen Sie dann Ihr Projekt aus, oder debuggen Sie es.

    Hinweis

    Nachdem Sie diese Schritte ausgeführt haben, können Sie mit dem Aktualisieren des App-Codes fortfahren und dann das aktualisierte Projekt auf dem Entwicklungscomputer debuggen, ohne neue App-Pakete an den Store zu übermitteln. Die Store-Version Ihrer App muss nur einmal auf Ihren Entwicklungscomputer heruntergeladen werden, um die lokale Lizenz zu erhalten, die zum Testen verwendet wird. Neue App-Pakete müssen nur an den Store übermittelt werden, wenn Sie Ihre Tests abgeschlossen haben und Kund*innen Features im Zusammenhang mit In-App-Käufen oder Testversionen zur Verfügung stellen möchten.

Wenn Ihre App den Namespace Windows.ApplicationModel.Store verwendet, können Sie die Klasse CurrentAppSimulator in Ihrer App verwenden, um während der Testphase Lizenzinformationen zu simulieren, bevor Sie Ihre App an den Store übermitteln. Weitere Informationen finden Sie unter Erste Schritte mit den Klassen CurrentApp und CurrentAppSimulator.

Hinweis

Der Namespace Windows.Services.Store stellt keine Klasse zum Simulieren von Lizenzinformationen während der Testphase bereit. Wenn Sie den Namespace Windows.Services.Store verwenden, um In-App-Käufe oder Testversionen zu implementieren, müssen Sie Ihre App wie weiter oben beschrieben im Store veröffentlichen und auf Ihr Entwicklungsgerät herunterladen, um die zugehörige Lizenz zu Testzwecken zu verwenden.

Belege für In-App-Käufe

Der Namespace Windows.Services.Store stellt keine API bereit, mit der Sie im Code Ihrer App einen Transaktionsbeleg für erfolgreiche Käufe abrufen können. Bei Apps, die den Namespace Windows.ApplicationModel.Store verwenden, ist das anders: Hier können Sie eine clientseitige API zum Abrufen eines Transaktionsbelegs verwenden.

Wenn Sie In-App-Käufe mit dem Namespace Windows.Services.Store implementieren und überprüfen möchten, ob ein bestimmter Kunde bzw. eine bestimmte Kundin eine App oder ein Add-On erworben hat, können Sie die Produktabfragemethode in der Microsoft Store-Sammlungs-API (eine REST-API) verwenden. Die Rückgabedaten für diese Methode geben Aufschluss darüber, ob der angegebene Kunde bzw. die angegebene Kundin über eine Berechtigung für ein bestimmtes Produkt verfügt, und enthalten Daten zu der Transaktion, mit der der Benutzer bzw. die Benutzerin das Produkt erworben hat. Die Microsoft Store-Sammlungs-API verwendet zum Abrufen dieser Informationen die Azure AD-Authentifizierung.

Verwenden der Klasse „StoreContext“ mit der Desktop-Brücke

Desktopanwendungen, die die Desktop-Brücke verwenden, können die Klasse StoreContext verwenden, um In-App-Käufe und Testversionen zu implementieren. Wenn Sie jedoch über eine Win32-Desktopanwendung oder über eine Desktopanwendung mit Fenster-Handle (HWND) verfügen, die dem Renderingframework zugeordnet ist (z. B. eine WPF-Anwendung oder eine Windows App SDK-Anwendung), muss für Ihre Anwendung das Objekt StoreContext konfiguriert werden, um anzugeben, welches Anwendungsfenster das Besitzerfenster für die von dem Objekt angezeigten modalen Dialogfelder ist.

Viele Member vom Typ StoreContext (sowie Member anderer verwandter Typen, auf die über das Objekt StoreContext zugegriffen wird) zeigen Benutzer*innen ein modales Dialogfeld für Store-bezogene Vorgänge wie den Kauf eines Produkts an. Wenn eine Desktopanwendung das Objekt StoreContext nicht konfiguriert, um das Besitzerfenster für modale Dialogfelder anzugeben, gibt dieses Objekt ungenaue Daten oder Fehler zurück.

Gehen Sie wie folgt vor, um ein Objekt vom Typ StoreContext in einer Desktopanwendung zu konfigurieren, die die Desktop-Brücke verwendet:

Ab .NET 6

Wenn Ihre Anwendung in C# mit .NET 6 oder einer höheren Version geschrieben wurde, führen Sie die folgenden Schritte aus:

  1. Stellen Sie sicher, dass die Eigenschaft TargetFramework in der Projektdatei auf eine bestimmte Windows SDK-Version festgelegt ist, um auf die Windows-Runtime-APIs zuzugreifen und so Zugriff auf den Namespace WinRT.Interop zu erhalten. Beispiel:

    <PropertyGroup>
  <!-- You can also target other versions of the Windows SDK and .NET, e.g. "net6.0-windows10.0.19041.0" -->
  <TargetFramework>net6.0-windows10.0.22000.0</TargetFramework>
</PropertyGroup>

  2. Rufen Sie mithilfe der Methode GetDefault (oder mithilfe von GetForUser, wenn Ihre App eine Mehrbenutzer-App ist) ein Objekt vom Typ StoreContext ab, wie weiter oben in diesem Artikel beschrieben. Verwenden Sie die Methoden WinRT.Interop.WindowNative.GetWindowHandle und WinRT.Interop.InitializeWithWindow.Initialize, um das Dialogfeld mit dem angegebenen Fensterhandle zu initialisieren. (Weitere Informationen finden Sie unter Abrufen eines Fensterhandles (HWND) sowie unter Anzeigen von WinRT UI-Objekten, die von CoreWindow abhängig sind.)

    StoreContext context = StoreContext.GetDefault();
// Obtain window handle by passing in pointer to the window object
var hwnd = WinRT.Interop.WindowNative.GetWindowHandle(windowObject);
// Initialize the dialog using wrapper function for IInitializeWithWindow
WinRT.Interop.InitializeWithWindow.Initialize(context, hwnd);

Ältere Versionen von .NET oder C++

Wenn Ihre Anwendung mit einer älteren Version von .NET oder in C++ geschrieben wurde, gehen Sie wie folgt vor:

  1. Führen Sie eine der folgenden Aktionen aus, um Ihrer App den Zugriff auf die Schnittstelle IInitializeWithWindow zu ermöglichen:

    • Wenn Ihre Anwendung in einer verwalteten Sprache wie C# oder Visual Basic (vor .NET 6) geschrieben wurde, deklarieren Sie die Schnittstelle IInitializeWithWindow im App-Code wie im folgenden C#-Beispiel mit dem Attribut ComImport. In diesem Beispiel wird davon ausgegangen, dass Ihre Codedatei über eine Anweisung vom Typ using für den Namespace System.Runtime.InteropServices verfügt.

      [ComImport]
[Guid("3E68D4BD-7135-4D10-8018-9FB6D9F33FA1")]
[InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
public interface IInitializeWithWindow
{
    void Initialize(IntPtr hwnd);
}

    • Wenn Ihre Anwendung in C++ geschrieben ist, fügen Sie in Ihrem Code einen Verweis auf die Headerdatei shobjidl.h hinzu. Diese Headerdatei enthält die Deklaration der Schnittstelle IInitializeWithWindow.

  2. Rufen Sie wie weiter oben in diesem Artikel beschrieben mithilfe der Methode GetDefault (oder mithilfe von GetForUser, falls Ihre App eine Mehrbenutzer-App ist) ein Objekt vom Typ StoreContext ab, und wandeln Sie es in ein Objekt vom Typ IInitializeWithWindow um. Rufen Sie dann die Methode IInitializeWithWindow.Initialize auf, und übergeben Sie das Handle des Fensters, das als Besitzer für modale Dialogfelder fungieren soll, die von Methoden des Typs StoreContext angezeigt werden. Das folgende C#-Beispiel zeigt, wie Sie das Handle des Hauptfensters Ihrer App an die Methode übergeben. Weitere Informationen finden Sie auch unter Abrufen eines Fensterhandles (HWND) und Anzeigen von WinRT UI-Objekten, die von CoreWindow abhängig sind.

    StoreContext context = StoreContext.GetDefault();
IInitializeWithWindow initWindow = (IInitializeWithWindow)(object)context;
initWindow.Initialize(System.Diagnostics.Process.GetCurrentProcess().MainWindowHandle);

Produkte, SKUs und Verfügbarkeiten

Jedes Produkt im Store verfügt über mindestens eine SKU, und jede SKU verfügt über mindestens eine Verfügbarkeit. Diese Konzepte werden in Partner Center für die meisten Entwickler*innen abstrahiert, und die meisten Entwickler*innen definieren nie SKUs oder Verfügbarkeiten für ihre Apps oder Add-Ons. Da das Objektmodell für Store-Produkte im Namespace Windows.Services.Store jedoch SKUs und Verfügbarkeiten umfasst, können Grundkenntnisse zu diesen Konzepten in bestimmten Szenarien hilfreich sein.

Object Beschreibung
Produkt Ein Produkt ist eine beliebige Art von Produkt, das im Store verfügbar ist. Hierzu zählen also auch Apps und Add-Ons.

Jedes Produkt im Store verfügt über ein entsprechendes Objekt vom Typ StoreProduct. Diese Klasse stellt Eigenschaften bereit, die Sie für den Zugriff auf Daten wie die Store-ID des Produkts, die Bilder und Videos für den Store-Eintrag und Preisinformationen verwenden können. Außerdem stellt sie Methoden bereit, die verwendet werden können, um das Produkt zu kaufen.
SKU Eine SKU ist eine bestimmte Version eines Produkts mit eigener Beschreibung, eigenem Preis und anderen individuellen Produktdetails. Jede App bzw. jedes Add-On verfügt über eine Standard-SKU. Die meisten Entwickler*innen haben in der Regel nur dann mehrere SKUs für eine App, wenn sie eine Vollversion ihrer App und eine Testversion veröffentlichen. (Im Store-Katalog ist jede dieser Versionen eine andere SKU der gleichen App.)

Manche Herausgeber haben die Möglichkeit, eigene SKUs zu definieren. Beispielsweise kann ein großer Spieleherausgeber für Märkte, auf denen kein rotes Blut zulässig ist, eine eigene SKU mit grünem Blut veröffentlichen und für alle anderen Märkte eine andere SKU mit rotem Blut verwenden. Alternativ kann ein Herausgeber, der digitale Videoinhalte verkauft, zwei SKUs für ein Video veröffentlichen, um eine HD- und eine SD-Version des Videos anzubieten.

Jede SKU im Store verfügt über ein entsprechendes Objekt vom Typ StoreSku. Jedes Objekt vom Typ StoreProduct verfügt über eine Eigenschaft vom Typ Skus, die Sie verwenden können, um auf die SKUs für das Produkt zuzugreifen.
Verfügbarkeit Eine Verfügbarkeit ist eine bestimmte Version einer SKU mit eigenen Preisinformationen. Jede SKU verfügt über eine Standardverfügbarkeit. Einige Herausgeber haben die Möglichkeit, eigene Verfügbarkeiten zu definieren, um verschiedene Preisoptionen für eine bestimmte SKU einzuführen.

Jede Verfügbarkeit im Store verfügt über ein entsprechendes Objekt vom Typ StoreAvailability. Jedes Objekt vom Typ StoreSku verfügt über eine Eigenschaft vom Typ Availabilities, die Sie verwenden können, um auf die Verfügbarkeiten für die SKU zuzugreifen. Bei den meisten Entwickler*innen verfügt jede SKU nur über eine einzelne Standardverfügbarkeit.

Store-IDs

Jeder App, jedem Add-On und jedem anderen Produkt im Store ist eine Store-ID (manchmal auch Produkt-Store-ID genannt) zugeordnet. Viele APIs benötigen die Store-ID, um einen Vorgang für eine App oder für ein Add-On ausführen zu können.

Die Store-ID eines Produkts im Store ist eine 12-stellige alphanumerische Zeichenfolge wie etwa 9NBLGGH4R315. Es gibt verschiedene Möglichkeiten, die Store-ID für ein Produkt im Store abzurufen:

  • Für eine App können Sie die Store-ID auf der Seite App-Identität in Partner Center abrufen.
  • Für ein Add-On können Sie die Store-ID auf der Übersichtsseite des Add-Ons in Partner Center abrufen.
  • Die Store-ID eines beliebigen Produkts kann auch programmgesteuert abgerufen werden. Verwenden Sie hierzu die Eigenschaft StoreId des Objekts StoreProduct, das das Produkt darstellt.

Bei Produkten mit SKUs und Verfügbarkeiten verfügen die SKUs und Verfügbarkeiten über eigene Store-IDs mit unterschiedlichen Formaten.

Object Store-ID-Format
SKU Die Store-ID für eine SKU hat das Format <product Store ID>/xxxx, wobei xxxx eine vierstellige alphanumerische Zeichenfolge ist, die eine SKU für das Produkt identifiziert. Beispielsweise 9NBLGGH4R315/000N. Diese ID wird von der Eigenschaft StoreId eines Objekts vom Typ StoreSku zurückgegeben und mitunter als SKU-Store-ID bezeichnet.
Verfügbarkeit Die Store-ID für eine Verfügbarkeit hat das Format <product Store ID>/xxxx/yyyyyyyyyyyy, wobei xxxx eine vierstellige alphanumerische Zeichenfolge ist, die eine SKU für das Produkt identifiziert, und yyyyyyyyyyyy eine zwölfstellige alphanumerische Zeichenfolge, die eine Verfügbarkeit für die SKU identifiziert. Beispielsweise 9NBLGGH4R315/000N/4KW6QZD2VN6X. Diese ID wird von der Eigenschaft StoreId eines Objekts vom Typ StoreAvailability zurückgegeben und mitunter als Verfügbarkeits-Store-ID bezeichnet.

Verwenden von Produkt-IDs für Add-Ons in Ihrem Code

Falls Sie ein Add-On im Kontext Ihrer App für Kund*innen verfügbar machen möchten, müssen Sie für Ihr Add-On eine eindeutige Produkt-ID eingeben, wenn Sie Ihre Add-On-Übermittlung in Partner Center erstellen. Mit dieser Produkt-ID können Sie in Ihrem Code auf das Add-On verweisen. Die spezifischen Szenarien, in denen Sie die Produkt-ID verwenden können, hängen allerdings davon ab, welchen Namespace Sie für In-App-Käufe in Ihrer App verwenden.

Hinweis

Die Produkt-ID, die Sie in Partner Center für ein Add-On eingeben, unterscheidet sich von der Store-ID des Add-Ons. Die Store-ID wird von Partner Center generiert.

Apps, die den Namespace „Windows.Services.Store“ verwenden

Wenn Ihre App den Namespace Windows.Services.Store verwendet, können Sie mithilfe der Produkt-ID ganz einfach das Objekt vom Typ StoreProduct identifizieren, das Ihr Add-On darstellt, oder das Objekt StoreLicense, das die Lizenz Ihres Add-Ons darstellt. Die Produkt-ID wird durch die Eigenschaften StoreProduct.InAppOfferToken und StoreLicense.InAppOfferToken verfügbar gemacht.

Hinweis

Die Produkt-ID ist zwar eine praktische Möglichkeit, um ein Add-On in Ihrem Code zu identifizieren, die meisten Vorgänge im Namespace Windows.Services.Store verwenden jedoch die Store-ID eines Add-Ons anstatt der Produkt-ID. Um also beispielsweise einzelne oder mehrere bekannte Add-Ons für eine App programmgesteuert abzurufen, übergeben Sie die Store-IDs (anstelle der Produkt-IDs) der Add-Ons an die Methode GetStoreProductsAsync. Um ein verbrauchsbasiertes Add-On als erfüllt zu melden, übergeben Sie die Store-ID des Add-Ons (anstelle der Produkt-ID) an die Methode ReportConsumableFulfillmentAsync.

Apps, die den Namespace „Windows.ApplicationModel.Store“ verwenden

Wenn Ihre App den Namespace Windows.ApplicationModel.Store verwendet, muss für die meisten Vorgänge die Produkt-ID verwendet werden, die Sie einem Add-On in Partner Center zuweisen. Beispiel: