Éditeur Microsoft Store

Utilisez cette compétence lorsque l'utilisateur souhaite publier une application Windows dans le Microsoft Store, créer ou valider un MSIX, finaliser une soumission Partner Center, répondre à des conclusions de certification ou surveiller l'état de la publication.

Cette compétence concerne les applications de bureau Windows, y compris les applications Win32 classiques packagées qui utilisent runFullTrust. Elle repose sur une soumission de bout en bout réussie utilisant Partner Center, un MSIX Store non signé, le Windows App Certification Kit et l'automatisation de navigateur sur les composants web actuels de Partner Center.

Garanties de sécurité obligatoires

Traitez Partner Center comme un système de publication en production.

N'acceptez jamais le Contrat de développeur d'application Microsoft ou tout autre accord contraignant sans une confirmation utilisateur fraîche et spécifique à l'action.
N'appuyez jamais sur Soumettre pour certification sans une confirmation utilisateur fraîche et spécifique à l'action après que chaque section soit complète et que le paquet final soit validé.
N'annulez jamais la certification, ne supprimez pas une soumission, ne changez pas la tarification, ne changez pas la disponibilité du marché, ne publiez pas manuellement ni n'envoyez de retours Partner Center sans confirmation pour cette action exacte.
N'entrez, ne récupérez, n'imprimez, n'enregistrez ni n'exposez jamais les mots de passe, clés d'accès, tokens, codes de récupération, codes MFA ou informations de paiement. Laissez l'utilisateur finaliser les invites d'authentification des identifiants et du système d'exploitation.
N'utilisez pas le profil de navigateur quotidien de l'utilisateur pour l'automatisation. Utilisez un profil persistant dédié et laissez l'utilisateur s'authentifier de manière interactive.
N'inférez pas de conformité juridique, marque déposée, brevet, confidentialité, contrôle des exportations ou open-source. Identifiez la préoccupation et déclarez quand un examen professionnel est judicieux.
Ne prétendez pas que WACK a réussi à partir d'un code de sortie seul. Trouvez et lisez le rapport généré et vérifiez son résultat global.
N'uploadez pas un paquet tant que son identité, éditeur, nom d'affichage, architecture, version et état de signature n'ont pas été inspectés.

Fichiers de cette compétence

references/submission-playbook.md - séquence de soumission complète.
references/msix-checklist.md - exigences de paquet et de manifeste.
references/partner-center-dom.md - routes connues, texte, rôles, éléments personnalisés, sélecteurs et particularités d'automatisation.
references/worked-example.md - leçons concrètes d'une soumission réussie d'application de bureau full-trust.
scripts/partner-center-control.mjs - contrôleur Playwright pour un profil Edge dédié.
scripts/inspect-msix.ps1 - dépacker et inspecter un MSIX avant l'upload.
scripts/invoke-wack.ps1 - exécuter WACK, puis trouver, vérifier et enregistrer ses rapports XML et HTML.
templates/run-full-trust-rationale.md - explication de capacité restreinte.
templates/certification-notes.md - instructions de testeur.
templates/store-listing.md - feuille de contenu de liste.
templates/submission-record.json - enregistrement durable d'identité, paquet, validation et remise de certification.

Lisez la référence pertinente avant de réaliser cette phase. Ne vous fiez pas aux étiquettes Partner Center mémorisées car Microsoft change l'interface utilisateur.

Flux de travail de bout en bout

1. Établir la portée et la préparation

Collectez ou déterminez :

Nom de l'application et nom du produit Store réservé.
Référentiel et commande de compilation.
Version de l'application et version MSIX prévue.
Architectures supportées et version Windows minimale.
Si l'application est WinUI, UWP, Win32 packagé, Electron, Wails, Tauri, .NET ou une autre technologie de bureau.
Exécutables natifs, processus auxiliaires, services, pilotes, tâches de démarrage, gestionnaires de protocole, associations de fichiers, codecs et capacités restreintes.
Politique de confidentialité, URL de support, site web, licences, avis et obligations de source correspondantes.
Exigences réelles d'appareil et de réseau pour la certification.
Le compte Microsoft que l'utilisateur souhaite sélectionner lors de la connexion.

Inspectez le référentiel avant de proposer des modifications de paquet. Recherchez les modèles de manifeste existants, les scripts de paquet, les scripts de signature, les icônes d'application, les sources de version, les documents de confidentialité, les avis tiers et le comportement au démarrage.

2. Réserver le produit et capturer l'identité

Dans Partner Center, réservez un nom de produit disponible. Évitez les termes déposés dans le nom du produit à moins que l'utilisateur n'ait un droit documenté de les utiliser.

Après la réservation, capturez les valeurs exactes sous :

Gestion du produit > Identité du produit

ID du produit Store
Nom d'identité du paquet
ID de l'éditeur, généralement une valeur CN=...
Nom d'affichage de l'éditeur
Nom de la famille de paquets
Nom d'affichage du produit réservé
URL publique du Store

Ne devinez jamais ces valeurs. Le MSIX doit utiliser exactement les valeurs de Partner Center.

3. Créer le paquet Store

Suivez references/msix-checklist.md.

Défauts importants :

Un MSIX de soumission Microsoft Store doit être non signé. Microsoft le signe après certification.
Un paquet distribué en dehors du Store doit être signé avec un certificat dont le sujet correspond exactement à l'éditeur du manifeste.
Le quatrième composant de version doit être 0 avant la soumission au Store car il est réservé à Microsoft.
Le premier composant de version doit être non nul.
Package/Properties/DisplayName doit correspondre exactement à un nom de produit réservé. Correspondre seulement au nom d'affichage visuel de l'application n'est pas suffisant.

Préférez un script de compilation répétable qui :

Valide les versions d'entrée et les valeurs d'identité.
Compile ou reçoit l'exécutable de production.
Prépare le manifeste, l'exécutable, les ressources, les licences, les informations de confidentialité, les avis et les liens source.
Empaque avec makeappx.exe.
Dépacquète le MSIX généré dans un répertoire de vérification.
Vérifie le hash de l'exécutable dépaqueté.
Émet un reçu JSON avec les valeurs d'identité et les hashes SHA-256.

4. Inspecter et tester le MSIX

Exécutez :

.\scripts\inspect-msix.ps1 `
  -PackagePath '<path-to-package.msix>' `
  -ExpectedIdentityName '<Partner Center identity name>' `
  -ExpectedPublisher '<Partner Center publisher ID>' `
  -ExpectedDisplayName '<reserved product name>'

Le script appartient au répertoire de cette compétence, pas nécessairement au référentiel de l'application. Résolvez son chemin complet avant de l'invoquer.

Installez et exercez l'application packagée sous une identité de paquet réelle si possible. Testez :

Premier lancement et mise à niveau.
Tâches de démarrage et paramètres persistants.
Lancement du processus auxiliaire.
Comportement de la barre d'état système et fermeture propre.
Découverte réseau et comportement du pare-feu.
Accès aux fichiers et au registre sous l'identité du paquet.
Comportement de désinstallation et de rétention des données.
Comportement des capacités restreintes.

5. Exécuter WACK

Exécutez :

# Exécutez cette commande depuis un terminal PowerShell élevé.
.\scripts\invoke-wack.ps1 `
  -PackagePath '<path-to-package.msix>' `
  -ReportPath '<artifact-directory>\WACK-report.xml'

Le lanceur WACK en ligne de commande nécessite une élévation. Le modèle ne doit pas approuver l'invite d'authentification du système d'exploitation pour l'utilisateur.

WACK accepte un chemin de rapport uniquement s'il se termine par .xml. Tout autre extension échoue avec le code de sortie -1 et The report output file path should point to a XML file. Les kits actuels écrivent le rapport XML au chemin demandé et un rendu HTML de celui-ci à %LOCALAPPDATA%\Microsoft\AppCertKit\<same base name>.htm. Une exécution antérieure a laissé uniquement un rapport HTML dans ce dossier et aucun rapport XML.

Le script :

Passe toujours à WACK un chemin .xml. Un -ReportPath se terminant par .htm ou .html nomme le rapport HTML enregistré, et le rapport XML est enregistré à côté avec le même nom de base.
Utilise le rapport XML de cette exécution au chemin demandé, ou sinon le rapport WACK le plus récent dans %LOCALAPPDATA%\Microsoft\AppCertKit. Il saute les fichiers d'exécutions antérieures et les fichiers XML sans rapport que WACK conserve dans ce dossier, et continue d'attendre pendant que le rapport est toujours un rapport intermédiaire inachevé.
Associe le rapport HTML au rapport XML par heure de rapport, puis enregistre les deux à côté de -ReportPath.
Rapporte le OVERALL_RESULT XML de la manière que le rapport HTML l'affiche : PASS est PASSED, FAIL est FAILED, WARNING est PASSED WITH WARNINGS, et un rapport intermédiaire est INCOMPLETE. Le résultat HTML est utilisé seulement quand il n'y a pas de rapport XML.
Échoue lorsque le résultat n'est pas PASSED, que tous les tests n'ont pas été exécutés, que les rapports XML et HTML ne concordent pas, que appcert.exe a quitté avec une erreur, ou que le nom d'identité du paquet ou la version du rapport ne correspond pas au paquet. Pour un bundle, il avertit à la place, vérifiez donc le nom et la version à la main.
Liste chaque test qui n'a pas réussi dans nonPassingTests, avec les messages WACK pour cela. Un résultat HTML uniquement laisse cette liste vide.

Quand il trouve un rapport, le script imprime un résumé JSON, puis lève une exception si passed est false. Ne continuez pas vers la soumission à moins que passed soit true. PASSED WITH WARNINGS n'est pas PASSED : corrigez les tests qu'il nomme et réexécutez WACK. Lisez chaque entrée dans warnings. Les échecs de test optionnels ne bloquent pas l'intégration au Store, mais enquêtez sur eux.

Enregistrez le résultat dans l'enregistrement de soumission : overallResult en tant que wack.result, xmlReport en tant que wack.reportPath, kitVersion en tant que wack.kitVersion, et reportTime en tant que wack.testedAt. Quand resultSource est html, utilisez htmlReport comme chemin du rapport et copiez la version du kit et l'heure du rapport à partir de l'en-tête du rapport HTML.

Pour analyser et vérifier un rapport existant sans réexécuter WACK :

.\scripts\invoke-wack.ps1 `
  -PackagePath '<path-to-package.msix>' `
  -ReportPath '<artifact-directory>\verified-WACK-report.xml' `
  -ExistingReportPath '<existing-WACK-report.xml>'

Passez un rapport .htm seulement quand aucun rapport XML n'existe. Donné un rapport XML, le script cherche le rapport HTML avec le même nom de base, à côté de lui ou dans %LOCALAPPDATA%\Microsoft\AppCertKit, et l'utilise quand les heures de rapport concordent. Donné un rapport HTML, il utilise le rapport XML à côté quand les deux concordent.

6. Automatiser Partner Center avec prudence

Préférez les outils de navigateur natifs d'application ou d'utilisation d'ordinateur quand ils peuvent inspecter et agir sur la page de manière fiable. Utilisez scripts/partner-center-control.mjs comme solution de secours quand les composants web Partner Center ou les uploads de fichiers ne sont pas fiables.

Configuration :

Set-Location '<skill-directory>\scripts'
npm install
$env:PARTNER_CENTER_PROFILE = '<dedicated-profile-directory>'
node .\partner-center-control.mjs launch

Exécutez launch comme processus d'arrière-plan attaché. L'utilisateur finalise l'authentification Microsoft dans la fenêtre Edge dédiée. Dans un processus de commande séparé, utilisez des commandes en lecture seule telles que :

node .\partner-center-control.mjs status
node .\partner-center-control.mjs pages
node .\partner-center-control.mjs text
node .\partner-center-control.mjs anchors
node .\partner-center-control.mjs overview-state
node .\partner-center-control.mjs agreement-state
node .\partner-center-control.mjs button-state "Submit for certification"

Les commandes du contrôleur qui changent d'état nécessitent :

$env:PARTNER_CENTER_ALLOW_WRITE = '1'

Ne le définissez que après que l'utilisateur ait autorisé l'action exacte. Supprimez-le après l'action afin que les commandes ultérieures échouent fermées.

Lisez references/partner-center-dom.md avant d'utiliser les sélecteurs.

7. Finaliser chaque section de soumission

Lisez references/submission-playbook.md. Les sections typiques sont :

Tarification et disponibilité
Propriétés
Classifications par âge
Paquets
Listings du Store
Options de soumission
Informations de test supplémentaires

Après avoir enregistré chaque section, rechargez-la et vérifiez la persistance. Partner Center peut temporairement omettre les états d'achèvement pendant que ses API se chargent toujours. Attendez et rechargez avant de décider qu'une section est incomplète.

Ne faites pas de déclarations de marketing ou d'accessibilité non supportées. Utilisez des captures d'écran d'application authentiques. Décrivez plainement les limitations de réseau, de matériel, de compte et de contenu protégé.

Pour runFullTrust, expliquez la fonctionnalité native exacte, les processus auxiliaires, les APIs Windows, l'intégration au démarrage, et pourquoi un modèle d'application sandboxé est insuffisant. Déclarez si l'application utilise l'élévation, les services, les pilotes, les paramètres à l'échelle du système ou un backend cloud.

8. Examen final de préparation

Avant de demander l'approbation de soumission, vérifiez :

Chaque section Partner Center dit Complète.
Le paquet dit Validé.
invoke-wack.ps1 a rapporté passed: true pour le paquet final : le résultat global WACK est PASSED, et le nom d'identité et la version du rapport correspondent au paquet.
L'identité du paquet et le nom d'affichage correspondent à Partner Center.
Le paquet n'est pas signé pour la soumission au Store.
La confidentialité, le support, le site web, la licence et les avis sont accessibles.
Les notes de certification sont enregistrées et incluent des instructions de test reproductibles.
Les capacités restreintes ont des explications.
Le calendrier de publication est ce que l'utilisateur a l'intention.
Aucun bloquer connu n'est caché.

9. Acceptation d'accord

Si Partner Center affiche un accord mis à jour :

Ouvrez la page des accords et identifiez le nom et la version exacts de l'accord.
Dites à l'utilisateur que c'est un accord juridique contraignant régissant le compte de développeur et les soumissions au Store.
Demandez l'approbation explicite d'accepter cette version exacte.
Réinspectez la page après approbation.
Acceptez seulement la ligne prévue une fois.
Vérifiez que l'état a changé de Not Accepted à une date d'acceptation.

Ne réutilisez pas l'approbation d'un autre accord ou d'une action antérieure.

10. Soumettre pour certification

Quand le bouton est activé :

Déclarez que la soumission envoie le produit à la certification Microsoft et s'il sera publié automatiquement en cas d'approbation.
Demandez l'approbation explicite d'appuyer sur Soumettre pour certification.
Réinspectez le bouton après approbation.
Cliquez dessus une fois.
Ne soumettez pas le sondage de retours optionnel sans approbation séparée.
Vérifiez que la vue d'ensemble dit En certification et affiche le pipeline de certification.

11. Surveiller et répondre

La certification se termine généralement en quelques heures mais peut prendre plusieurs jours ouvrables. Surveillez :

Soumission
Prétraitement
Certification
Publication

Si la certification échoue, citez exactement la conclusion, mappez-la au paquet, à la listing, à la politique ou au comportement du test, apportez la plus petite correction complète, recompilez avec une version de paquet supérieure si nécessaire, réexécutez l'inspection et WACK, et obtenez l'approbation de soumission fraîche.

Si le produit est approuvé, vérifiez l'URL publique du Store à partir d'un contexte non authentifié. Ne prétendez pas qu'il est en direct simplement parce que Partner Center dit que la publication s'est terminée.

Norme de sortie

Rapportez l'état concret :

ID du produit et nom réservé.
Chemin du paquet, version du paquet, architecture, état de signature et SHA-256.
Résultat WACK et chemin du rapport.
Sections Partner Center complétées.
Nom d'accord et état d'acceptation.
Étape du pipeline de certification.
Bloqueurs exacts et action suivante.

Ne rapportez jamais une mutation comme complète à moins que l'état résultant n'ait été relû à partir de Partner Center ou que l'artefact généré n'ait été inspecté.

Pour les soumissions longues, copiez templates/submission-record.json dans un répertoire d'artefacts de session et mettez-le à jour après chaque changement d'état significatif. Ne validez pas les identifiants de compte, les URL privées, les identifiants ou les données de profil de navigateur dans le référentiel de l'application.

microsoft-store-publisher