In-App-Käufe und Testversionen

  • Artikel

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

  • In-App-Käufe Unabhängig davon, ob Ihre App kostenlos ist oder nicht, können Sie Inhalte oder neue App-Funktionen (z. B. das Entsperren der nächsten Ebene eines Spiels) direkt in der App verkaufen.

  • Testfunktionalität Wenn Sie Ihre App als kostenlose Testversion in Partner Center konfigurieren, können Sie Ihre Kunden dazu verleiten, die Vollversion Ihrer App zu erwerben, indem Sie einige Features während des Testzeitraums ausschließen oder einschränken. Außerdem können Sie Features wie Banner oder Wasserzeichen aktivieren, die nur in der Testversion angezeigt werden, bevor ein Kunde Ihre App kauft.

Dieser Artikel enthält eine Übersicht darüber, wie In-App-Käufe und Testversionen in UWP-Apps funktionieren.

Auswahl des zu verwendenden Namespace

Es gibt zwei verschiedene Namespaces, die Sie verwenden können, um In-App-Käufe und Testfunktionen zu Ihren UWP-Apps hinzuzufügen, je nachdem, welche Version von Windows 10 oder Windows 11 Ihre Apps als Ziel verwenden. Obwohl die APIs in diesen Namespaces den gleichen Ziele dienen, sind sie unterschiedlich gestaltet, und der Code ist zwischen den beiden APIs nicht kompatibel.

  • Windows.Services.Store Ab Windows 10 Version 1607 können Apps die API in diesem Namespace verwenden, um In-App-Käufe und Testversionen zu implementieren. Es wird empfohlen, die Member in diesem Namespace zu verwenden, wenn Ihr App-Projekt Windows 10 Anniversary Edition (10.0; Build 14393) oder eine höhere Version in Visual Studio. Dieser Namespace unterstützt die neuesten Add-On-Typen, z. B. vom Store verwaltete Verbrauchs-Add-Ons, und ist so konzipiert, dass er mit zukünftigen Produkttypen und Features kompatibel ist, die von Partner Center und dem Store unterstützt werden. Weitere Informationen zu diesem Namespace finden Sie in diesem Artikel im Abschnitt In-App-Käufe und Testversionen mit dem Windows.Services.Store-Namespace.

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

Wichtig

Der Windows.ApplicationModel.Store-Namespace wird nicht mehr mit neuen Features aktualisiert, und es wird empfohlen, stattdessen den Windows.Services.Store-Namespace für Ihre App zu verwenden. Der Windows.ApplicationModel.Store-Namespace wird nicht in Windows-Desktopanwendungen unterstützt, die die Desktop-Brücke verwenden, oder in Apps oder Spielen, die eine Entwicklungssandbox im Partner Center verwenden (dies gilt z. B. für alle Spiele, die in Xbox Live integriert sind).

Grundlegende Konzepte

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

Ein Add-On ist ein Produkt oder Feature, das Sie Ihren Kunden im Kontext Ihrer App zur Verfügung stellen: z. B. Währung, die in einer App oder einem Spiel verwendet werden soll, neue Karten oder Waffen für ein Spiel, die Möglichkeit, Ihre App ohne Werbung zu verwenden, oder digitale Inhalte wie Musik oder Videos für Apps, die diese Art von Inhalt anbieten können. Jede App und jedes Add-On verfügt über eine zugehörige Lizenz, die angibt, ob der Benutzer zur Verwendung dieser App oder des Add-Ons berechtigt ist. Wenn der Benutzer berechtigt ist, die App bzw. das Add-On als Testversion zu verwenden, enthält die Lizenz auch zusätzliche Informationen zur Testversion.

Um Kunden in Ihrer App ein Add-On anbieten zu können, müssen Sie das Add-On für Ihre App in Partner Center definieren , damit der Store davon weiß. Anschließend kann das Add-On mithilfe der APIs im Windows.Services.Store-Namespace oder im Windows.ApplicationModel.Store-Namespace den Kunden zum Erwerb als In-App-Kauf angeboten werden.

Für UWP-Apps können die folgenden Arten von Add-Ons angeboten werden.

Add-On-Typ BESCHREIBUNG
Durable Ein Add-On, das für die von Ihnen in Partner Center angegebene Lebensdauer beibehalten wird.

Standardmäßig laufen Gebrauchsgut-Add-Ons nie ab, in diesem Fall können sie nur einmal gekauft werden. Wenn Sie eine bestimmte Dauer für das Add-On angeben, kann der Benutzer das Add-On erneut kaufen, nachdem es abgelaufen ist.
Von Entwicklern verwaltetes Endverbraucher-Add-On Ein Add-On, das gekauft, verwendet und dann erneut erworben werden kann, nachdem es verwendet wurde. Sie sind dafür verantwortlich, den Saldo der Elemente, die das Add-On darstellt, des Benutzers nachzuverfolgen.

Wenn der Benutzer elemente verwendet, die dem Add-On zugeordnet sind, sind Sie dafür verantwortlich, das Guthaben des Benutzers zu erhalten und den Kauf des Add-Ons als erfüllt an den Store zu melden, nachdem der Benutzer alle Elemente verbraucht hat. Der Benutzer kann das Add-On erst dann erneut kaufen, nachdem Ihre App den vorherigen Kauf des Add-Ons als erfüllt gemeldet hat.

Wenn beispielsweise das Add-On 100 Münzen in einem Spiel darstellt und der Benutzer 10 Münzen nutzt, muss die App oder der Dienst den neuen Restbetrag von 90 Münzen für den Benutzer verwalten. Nachdem der Benutzer alle 100 Münzen genutzt hat, muss die App das Add-On als erfüllt melden, und danach kann der Benutzer das Add-On für 100 Münzen erneut kaufen.
Vom Store verwaltetes Endverbraucher-Add-On Ein Add-On, das jederzeit erworben, verwendet und erneut erworben werden kann. Der Store verfolgt den Saldo der Elemente des Benutzers, die das Add-On darstellt.

Wenn der Benutzer Elemente nutzt, die dem Add-On zugeordnet sind, sind Sie dafür verantwortlich, diese Elemente als erfüllt an den Store zu melden, und der Store aktualisiert den Saldo des Benutzers. Der Benutzer kann das Add-On beliebig oft erwerben (er muss die Elemente nicht zuerst nutzen). Ihre App kann das aktuelle Guthaben für den Benutzer jederzeit abfragen.

Wenn Ihr Add-On beispielsweise eine anfängliche Menge von 100 Münzen in einem Spiel darstellt und der Benutzer 50 Münzen verbraucht, meldet Ihre App dem Store, dass 50 Einheiten des Add-Ons erfüllt wurden, und der Store aktualisiert den verbleibenden Saldo. Wenn der Benutzer ihr Add-On dann erneut kauft, um 100 weitere Münzen zu erwerben, verfügt er jetzt über insgesamt 150 Münzen.

Hinweis Um vom Store verwaltete Verbrauchsmaterialien verwenden zu können, muss Ihre App Windows 10 Anniversary Edition (10.0; Build 14393) oder eine höhere Version in Visual Studio, und es muss den Windows.Services.Store-Namespace anstelle des Windows.ApplicationModel.Store-Namespace verwenden.
Subscription Ein dauerhaftes Add-On, bei dem der Kunde weiterhin in regelmäßigen Abständen in Rechnung gestellt wird, um das Add-On weiterhin zu verwenden. Der Kunde kann das Abonnement jederzeit kündigen, um weitere Gebühren zu vermeiden.

Hinweis Um Abonnement-Add-Ons verwenden zu können, muss Ihre App Windows 10 Anniversary Edition (10.0; Build 14393) oder eine höhere Version in Visual Studio, und es muss den Windows.Services.Store-Namespace anstelle des Windows.ApplicationModel.Store-Namespace verwenden.

Hinweis

Andere Arten von Add-Ons, z. B. dauerhafte Add-Ons mit Paketen (auch als herunterladbarer Inhalt oder DLC bezeichnet), sind nur für eine eingeschränkte Gruppe von Entwicklern verfügbar und werden in dieser Dokumentation nicht behandelt.

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

Dieser Abschnitt bietet eine Übersicht über wichtige Aufgaben und Konzepte für den Windows.Services.Store-Namespace . Dieser Namespace ist nur für Apps verfügbar, die Windows 10 Anniversary Edition (10.0; Build 14393) oder eine höhere Version in Visual Studio (dies entspricht Windows 10, Version 1607). Es wird empfohlen, dass Apps nach Möglichkeit den Windows.Services.Store-Namespace anstelle des Windows.ApplicationModel.Store-Namespace verwenden. Informationen zum Windows.ApplicationModel.Store Namespace finden Sie in diesem Artikel.

In diesem Abschnitt

Video

Sehen Sie sich das folgende Video an, um eine Übersicht darüber zu finden, wie Sie In-App-Käufe in Ihrer App mithilfe des Windows.Services.Store-Namespace implementieren.

Erste Schritte mit der StoreContext-Klasse

Der Haupteinstiegspunkt in den Windows.Services.Store-Namespace ist die StoreContext-Klasse. Diese Klasse stellt Methoden bereit, mit denen Sie Informationen für die aktuelle App und die verfügbaren Add-Ons abrufen, eine App oder ein Add-On für den aktuellen Benutzer kaufen, Lizenzinformationen für die aktuelle App oder die Add-Ons abrufen und weitere Aufgaben durchführen können. Gehen Sie zum Abrufen eines StoreContext-Objekts wie folgt vor:

  • Verwenden Sie in einer Einzelbenutzer-App (d. h. einer App, die nur im Kontext des Benutzers ausgeführt wird, der die App gestartet hat) die statische GetDefault-Methode , um ein StoreContext-Objekt abzurufen, mit dem Sie auf Microsoft Store-bezogene Daten für den Benutzer zugreifen können. Die meisten Apps für die universelle Windows-Plattform (UWP) sind Einzelbenutzer-Apps.

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

  • Verwenden Sie in einer Mehrbenutzer-App die statische GetForUser-Methode , um ein StoreContext-Objekt abzurufen, mit dem Sie auf Microsoft Store-bezogene Daten für einen bestimmten Benutzer zugreifen können, der während der Verwendung der App mit ihrem Microsoft-Konto angemeldet ist. Im folgenden Beispiel wird ein StoreContext-Objekt für den ersten verfügbaren Benutzer abgerufen.

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

Hinweis

Windows-Desktopanwendungen, die die Desktop-Brücke verwenden, müssen zusätzliche Schritte ausführen, um das StoreContext-Objekt zu konfigurieren, bevor sie dieses Objekt verwenden können. Weitere Informationen finden Sie in diesem Abschnitt.

Nachdem Sie über ein StoreContext-Objekt verfügen, können Sie beginnen, Methoden dieses Objekts aufzurufen, um Store-Produktinformationen und Lizenzinformationen für die aktuelle App und deren Add-Ons abzurufen, eine App oder ein Add-On für den aktuellen Benutzer zu erwerben und weitere Aufgaben auszuführen. Weitere Informationen zu den allgemeinen Aufgaben, die Sie mit diesem Objekt ausführen können, finden Sie in den folgenden Artikeln:

Eine Beispiel-App, die die Verwendung von StoreContext und anderen Typen im Windows.Services.Store-Namespace aufzeigt, finden Sie im Store-Beispiel.

Implementieren von In-App-Käufen

So bieten Sie den Kunden mit dem Windows.Services.Store-Namespace in Ihrer App In-App-Käufe an

  1. Wenn Ihre App Add-Ons bietet, die Kunden erwerben können, erstellen Sie Add-On-Übermittlungen für Ihre App im Partner Center .

  2. Schreiben Sie Code für Ihre App, um Produktinformationen über Ihre App oder ein von der App angebotenes Add-On abzurufen. Ermitteln Sie anschließend, ob die Lizenz aktiv ist (d. h., ob der Benutzer über eine Lizenz für die App bzw. das Add-On verfügt). Wenn die Lizenz nicht aktiv ist, zeigen Sie eine Benutzeroberfläche an, auf der die App bzw. das Add-On dem Benutzer als In-App-Kauf angeboten wird.

  3. Wenn sich der Benutzer für den Kauf Ihrer App oder Ihres Add-Ons entscheidet, verwenden Sie für den Erwerb des Produkts die geeignete Methode:

  4. Testen der Implementierung anhand der Hinweise für Tests in diesem Artikel.

Implementieren der Testfunktionen

So schränken Sie mit dem Windows.Services.Store-Namespace Features in einer Testversion Ihrer App ein oder schließen diese aus

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

  2. Schreiben Sie Code für Ihre App, um Produktinformationen über Ihre App oder ein von der App angebotenes Add-On abzurufen, und ermitteln Sie anschließend, ob es sich bei der der App zugeordneten Lizenz um eine Testlizenz handelt.

  3. Handelt es sich um eine Testversion der App, schließen Sie bestimmte Features aus oder schränken Sie sie ein, und aktivieren Sie diese, wenn der Benutzer eine Lizenz für die Vollversion erwirbt. Weitere Informationen und ein Codebeispiel finden Sie unter Implementieren einer Testversion der App.

  4. Testen der Implementierung anhand der Hinweise für Tests in diesem Artikel.

Testen der Implementierung für den In-App-Kauf oder die Testversion

Wenn Ihre App APIs im Windows.Services.Store-Namespace verwendet, um In-App-Kauf- oder Testfunktionen zu implementieren, müssen Sie Ihre App im Store veröffentlichen und die App auf Ihr Entwicklungsgerät herunterladen, um die Lizenz zum Testen zu verwenden. Führen Sie diesen Prozess aus, um Ihren Code zu testen:

  1. Wenn Ihre App noch nicht veröffentlicht und im Store verfügbar ist, stellen Sie sicher, dass Ihre App die Mindestanforderungen für das Zertifizierungskit für Windows-Apps erfüllt, übermitteln Sie Ihre App im Partner Center, und stellen Sie sicher, dass Ihre App den Zertifizierungsprozess besteht. Sie können Ihre App so konfigurieren, dass sie beim Testen nicht im Store auffindbar ist . Bitte beachten Sie die richtige Konfiguration von Pauschalflügen. Falsch konfigurierte Paketflüge können möglicherweise nicht heruntergeladen werden.

  2. Stellen Sie anschließend sicher, dass die folgenden Schritte durchgeführt wurden:

  3. Öffnen Sie Ihr Projekt in Visual Studio, klicken Sie auf das Menü „Projekt“, zeigen Sie auf Store, und klicken Sie dann auf App mit Store verknüpfen. Führen Sie die Anweisungen im Assistenten aus, um das App-Projekt der App in Ihrem Partner Center-Konto zuzuordnen, das Sie zum Testen verwenden möchten.

    Hinweis

    Wenn Sie Ihr Projekt nicht einer App im Store zuordnen, legen die StoreContext-Methoden die ExtendedError-Eigenschaft 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 App aus dem im vorherigen Schritt angegebenen Store, führen Sie die App einmal aus, und schließen Sie dann diese App. Damit wird sichergestellt, dass auf dem Gerät für die Entwicklung eine gültige Lizenz für die App installiert wird.

  5. Starten Sie in Visual Studio die Ausführung oder das Debuggen des Projekts. Der Code sollte App- und Add-On-Daten aus der Store-App abrufen, die Sie mit dem lokalen Projekt verknüpft haben. Wenn Sie zur Neuinstallation der App aufgefordert werden, folgen Sie den Anweisungen, und führen Sie dann das Projekt aus oder debuggen Sie es.

    Hinweis

    Nachdem Sie diese Schritte ausgeführt haben, können Sie den Code Ihrer App aktualisieren und dann Ihr aktualisiertes Projekt auf Ihrem Entwicklungscomputer debuggen, ohne neue App-Pakete an den Store zu übermitteln. Sie müssen die Store-Version Ihrer App nur einmal auf den Entwicklungscomputer herunterladen, um die lokale Lizenz zu erhalten, die zum Testen verwendet wird. Sie übermitteln neue App-Pakete erst an den Store, nachdem Sie die Tests abgeschlossen haben und Ihren Kunden App-Features zur Verfügung stellen möchten, die sich auf In-App-Käufe oder Testversionen beziehen.

Wenn Ihre App den Windows.ApplicationModel.Store-Namespace verwendet, können Sie die CurrentAppSimulator-Klasse in Ihrer App verwenden, um Lizenzinformationen während des Tests 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 Windows.Services.Store-Namespace stellt keine Klasse bereit, mit der Sie während der Tests Lizenzinformationen simulieren können. Wenn Sie den Windows.Services.Store-Namespace verwenden, um In-App-Käufe oder Testversionen zu implementieren, müssen Sie Ihre App im Store veröffentlichen und die App auf Ihr Entwicklungsgerät herunterladen, um die Lizenz für Tests zu verwenden, wie oben beschrieben.

Belege für In-App-Käufe

Der Windows.Services.Store-Namespace verfügt über keine API, mit der Sie im Code der App einen Transaktionsbeleg für erfolgreiche Käufe erhalten können. Dies unterscheidet sich von Apps, die den Windows.ApplicationModel.Store-Namespace verwenden, der zum Abrufen von Transaktionsbelegen eine clientseitige API verwenden kann.

Wenn Sie In-App-Käufe mithilfe des Windows.Services.Store-Namespace implementieren und überprüfen möchten, ob ein bestimmter Kunde eine App oder ein Add-On erworben hat, können Sie die Abfragemethode für Produkte in der Rest-API der Microsoft Store-Sammlung verwenden. Die für diese Methode zurückgegebenen Daten bestätigen, ob der jeweilige Kunde über eine Berechtigung für ein bestimmtes Produkt verfügt. Zudem werden Daten für die Transaktion bereitgestellt, im Rahmen derer der Benutzer das Produkt erworben hat. Die Microsoft Store-Sammlungs-API verwendet die Azure AD-Authentifizierung, um diese Informationen abzurufen.

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

Für Desktopanwendungen, die die Desktop-Brücke verwenden, kann zum Implementieren von In-App-Käufen und Testversionen die StoreContext-Klasse verwendet werden. Wenn Sie jedoch über eine Win32-Desktopanwendung oder eine Desktopanwendung mit einem Fensterhandle (HWND) verfügen, das dem Renderingframework zugeordnet ist (z. B. eine WPF- oder Windows App SDK-Anwendung), muss Ihre Anwendung das StoreContext-Objekt konfigurieren, um anzugeben, welches Anwendungsfenster das Besitzerfenster für modale Dialoge ist, die vom Objekt angezeigt werden.

Viele StoreContext-Member (und andere Member verwandter Typen, auf die über das StoreContext-Objekt zugegriffen wird) zeigen den Benutzern für Store-bezogene Vorgänge wie z. B. den Kauf eines Produkts ein modales Dialogfeld an. Wenn für eine Desktopanwendung das StoreContext-Objekt nicht konfiguriert wurde, um das Besitzerfenster für modale Dialogfelder anzugeben, gibt das Objekt ungenaue Daten oder Fehler zurück.

Führen Sie die folgenden Schritte durch, um ein StoreContext-Objekt in einer Desktopanwendung zu konfigurieren, die die Desktop-Brücke verwendet.

Für .NET 6 oder höher

Wenn Ihre Anwendung in C# mit .NET 6 oder höher geschrieben wird, führen Sie die folgenden Schritte aus.

  1. Stellen Sie sicher, dass die TargetFramework Eigenschaft in der Projektdatei auf eine bestimmte Windows SDK-Version festgelegt ist, um auf die Windows-Runtime-APIs zuzugreifen, die Zugriff auf den WinRT.Interop-Namespace bietet. 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 ein StoreContext-Objekt mithilfe der GetDefault-Methode (oder GetForUser , wenn Ihre App eine Mehrbenutzer-App ist) ab, wie weiter oben in diesem Artikel beschrieben). Verwenden Sie zum Initialisieren des Dialogfelds mit dem angegebenen Fensterhandle die Methoden WinRT.Interop.WindowNative.GetWindowHandle und WinRT.Interop.InitializeWithWindow.Initialize (siehe Abrufen eines Fensterhandles (HWND) und Anzeigen von WinRT-UI-Objekten, die von CoreWindow abhängen.

    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 funcion for IInitializeWithWindow
WinRT.Interop.InitializeWithWindow.Initialize(context, hwnd);

Für frühere Versionen von .NET oder C++

Wenn Ihre Anwendung mit einer früheren Version von .NET oder in C++ geschrieben wurde, führen Sie die folgenden Schritte aus.

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

    • Wenn Ihre Anwendung in einer verwalteten Sprache wie C# oder Visual Basic (vor .NET 6) geschrieben ist, deklarieren Sie die IInitializeWithWindow-Schnittstelle im Code Ihrer App mit dem ComImport-Attribut , wie im folgenden C#-Beispiel gezeigt. In diesem Beispiel wird davon ausgegangen, dass Ihre Codedatei über eine using-Anweisung für den System.Runtime.InteropServices-Namespace 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 im Code einen Verweis auf die shobjidl.h Headerdatei hinzu. Diese Headerdatei enthält die Deklaration der IInitializeWithWindow-Schnittstelle.

  2. Rufen Sie wie weiter oben in diesem Artikel beschrieben mit der GetDefault-Methode (oder GetForUser, falls Ihre App eine Mehrbenutzer-App ist) ein StoreContext-Objekt ab, und wandeln Sie es in ein IInitializeWithWindow-Objekt um. Rufen Sie dann die IInitializeWithWindow.Initialize-Methode auf, und übergeben Sie das Handle des Fensters, das der Besitzer aller modalen Dialoge sein soll, die durch StoreContext-Methoden angezeigt werden. Im folgenden C#-Beispiel wird gezeigt, wie das Handle des Hauptfensters der App an die Methode übergeben wird. 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 sind von den meisten Entwicklern in Partner Center abstrahiert, und die meisten Entwickler definieren nie SKUs oder Verfügbarkeiten für ihre Apps oder Add-Ons. Da das Objektmodell für Store-Produkte im Windows.Services.Store-Namespace jedoch SKUs und Verfügbarkeiten enthält, kann ein grundlegendes Verständnis dieser Konzepte für einige Szenarien hilfreich sein.

Object BESCHREIBUNG
Produkt Ein Produkt bezieht sich auf jeden Produkttyp, der im Store verfügbar ist, einschließlich einer App oder eines Add-Ons.

Jedes Produkt im Store verfügt über ein entsprechendes StoreProduct-Objekt . Diese Klasse stellt Eigenschaften für den Zugriff auf Daten bereit, z. B. die Store-ID des Produkts, die Bilder und Videos für den Store-Eintrag sowie Preisinformationen. Sie stellt außerdem Methoden bereit, mit denen Sie das Produkt kaufen können.
SKU Eine SKU ist eine bestimmte Version eines Produkts mit eigener Beschreibung, eigenem Preis und anderen eindeutigen Produktdetails. Jede App und jedes Add-On verfügt über eine Standard-SKU. Die meisten Entwickler verfügen nur dann über mehrere SKUs für eine App, wenn sie eine Vollversion der App und eine Testversion veröffentlichen (im Store-Katalog ist jede dieser Versionen eine andere SKU derselben App).

Einige Herausgeber können ihre eigenen SKUs definieren. Ein großer Spieleherausgeber kann z. B. ein Spiel mit einer SKU, die grünes Blut zeigt, in Märkten veröffentlichen, in denen kein rotes Blut zulässig ist, und eine andere SKU für rotes Blut in allen anderen Märkten. Alternativ kann ein Herausgeber, der digitale Videoinhalte verkauft, zwei SKUs für ein Video veröffentlichen, eine SKU für eine HD-Version und eine andere SKU für die SD-Version.

Jede SKU im Store verfügt über ein entsprechendes StoreSku-Objekt . Jedes StoreProduct verfügt über eine Skus-Eigenschaft , mit der Sie auf die SKUs für das Produkt zugreifen können.
Verfügbarkeit Eine Verfügbarkeit ist eine bestimmte Version einer SKU mit eigenen eindeutigen Preisinformationen. Jede SKU verfügt über eine Standardverfügbarkeit. Einige Herausgeber können eigene Verfügbarkeiten zum Vorstellen unterschiedlicher Preisoptionen für eine bestimmte SKU definieren.

Jede Verfügbarkeit im Store verfügt über ein entsprechendes StoreAvailability-Objekt . Jede StoreSku verfügt über eine Availabilities-Eigenschaft , die Sie verwenden können, um auf die Verfügbarkeiten für die SKU zuzugreifen. Für die meisten Entwickler verfügt jede SKU über eine einzelne Standardverfügbarkeit.

Store-IDs

Jede App, jedes Add-On oder ein anderes Produkt im Store verfügt über eine zugeordnete Store-ID (dies wird manchmal auch als Produktspeicher-ID bezeichnet). Viele APIs erfordern die Store-ID, um einen Vorgang für eine App oder ein Add-On auszuführen.

Die Store-ID eines Produkts im Store ist eine zwölfstellige alphanumerische Zeichenfolge, z. B. 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 im Partner Center abrufen.
  • Für ein Add-On können Sie die Store-ID auf der Übersichtsseite des Add-Ons in Partner Center abrufen.
  • Für jedes Produkt können Sie die Store-ID auch programmgesteuert abrufen, indem Sie die StoreId-Eigenschaft des StoreProduct-Objekts verwenden, das das Produkt darstellt.

Für Produkte mit SKUs und Verfügbarkeiten verfügen die SKUs und Verfügbarkeiten auch ü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 4-stellige alphanumerische Zeichenfolge ist, die eine SKU für das Produkt identifiziert. Beispiel: 9NBLGGH4R315/000N. Diese ID wird von der StoreId-Eigenschaft eines StoreSku-Objekts zurückgegeben und manchmal 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 4-stellige alphanumerische Zeichenfolge ist, die eine SKU für das Produkt identifiziert, und yyyyyyyyyyyy eine 12-stellige alphanumerische Zeichenfolge, die eine Verfügbarkeit für die SKU identifiziert. Beispiel: 9NBLGGH4R315/000N/4KW6QZD2VN6X. Diese ID wird von der StoreId-Eigenschaft eines StoreAvailability-Objekts zurückgegeben und manchmal als Verfügbarkeitsspeicher-ID bezeichnet.

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

Wenn Sie Ihren Kunden im Kontext Ihrer App ein Add-On zur Verfügung stellen möchten, müssen Sie eine eindeutige Produkt-ID für Ihr Add-On eingeben, wenn Sie Ihre Add-On-Übermittlung in Partner Center erstellen. Sie können diese Produkt-ID verwenden, um auf das Add-On in Ihrem Code zu verweisen, obwohl die spezifischen Szenarien, in denen Sie die Produkt-ID verwenden können, davon abhängen, 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 Windows.Services.Store-Namespace verwenden

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

Hinweis

Obwohl die Produkt-ID eine nützliche Möglichkeit ist, ein Add-On in Ihrem Code zu identifizieren, verwenden die meisten Vorgänge im Windows.Services.Store Namespace die Store-ID eines Add-Ons anstelle der Produkt-ID. Um beispielsweise ein 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 GetStoreProductsAsync-Methode . Um ein verbrauchsbares Add-On als erfüllt zu melden, übergeben Sie die Store-ID des Add-Ons (anstelle der Produkt-ID) an die ReportConsumableFulfillmentAsync-Methode .

Apps, die den Windows.ApplicationModel.Store-Namespace verwenden

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