Pièges du Store #1 : La dépendance de mon app a installé une entrée fantôme dans le menu Démarrer
2026-05-28
Tags : Windows · MSIX · Microsoft Store · Pièges du Store
Publier des applications Windows sur le Microsoft Store n'est pas toujours un long fleuve tranquille. Cette série documente les véritables pièges que j'ai rencontrés — un par article, court et pratique.
Voici le premier.
Contexte
RDP Heartbeat a commencé comme un outil Python + Tkinter — un petit point respirant qui indique si votre session RDP est toujours active. Ça fonctionnait, mais empaqueter une application desktop Python pour le Microsoft Store fut une épopée : source Python → exe PyInstaller → installateur Inno Setup → package MSIX. Nous avons raconté toute cette aventure dans un article.
Alors je l'ai entièrement réécrit en WinUI 3 natif avec Windows App SDK 2.0.1. La voie native devait être tranquille — plus besoin de gymnastique d'empaquetage Python. Et ça l'était, jusqu'à la certification du Store.
"Réussi avec correction requise"
Le résultat de la certification est revenu :
Status: Pass with required fix
10.1.1.11 On Device Tiles: Your submission installs multiple components to the device. Please make sure the additional installed components that are visible in the Start Menu have a unique name that clearly identifies which item is the main product.
Réussi — mais avec un avertissement. Quelque chose de supplémentaire était apparu dans le menu Démarrer, et ce n'était pas mon application.
L'entrée fantôme
Le rapport de certification indiquait que quelque chose de supplémentaire était apparu dans le menu Démarrer. J'ai regardé — et honnêtement, rien d'inhabituel. Mon menu Démarrer était exactement comme prévu, sans tuile supplémentaire.
J'ai passé en revue l'intégralité du projet : vérifié le manifeste du package, examiné la sortie du build, comparé avec mes autres applications du Store. Pas de packages supplémentaires, pas d'extensions suspectes, rien ne se démarquait.
Mais il y avait une différence. Mes autres applications — EnvStudio, GhostWin, QuickGUID — utilisent toutes Windows App SDK 1.8.x. RDP Heartbeat est la seule sur SDK 2.0.1. C'est la seule variable qui a changé.
Les applications WinUI 3 dépendent du runtime Windows App SDK, qui est distribué sous forme de packages MSIX installés comme dépendances système partagées. Le seul suspect que je puisse pointer est le runtime SDK 2.x — d'une manière ou d'une autre, sur l'environnement de test de Microsoft (mais pas sur ma machine), son déploiement produit une tuile visible dans le menu Démarrer. Pourquoi exactement, je ne sais pas.
Que pouvez-vous y faire ?
Voici la partie frustrante : vous ne pouvez pas le corriger directement. Les packages runtime sont créés par Microsoft — vous n'avez aucun contrôle sur la façon dont ils apparaissent dans le menu Démarrer.
Vos options pratiques :
- L'accepter et le documenter — Ajoutez une note dans votre soumission au Store expliquant que la tuile supplémentaire est une dépendance runtime fournie par Microsoft et non un produit distinct. C'est ce que j'ai fait, et la certification a été validée.
- Passer au déploiement autonome — Intégrez le runtime directement dans votre package d'application en définissant
<WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>dans votre fichier.csproj. Cela élimine entièrement la DEPN, mais ajoute environ 40 Mo par architecture à la taille du téléchargement.
La leçon à retenir
Si vous développez avec Windows App SDK 2.x pour le Microsoft Store :
- Sachez que la dépendance runtime peut créer une tuile visible dans le menu Démarrer
- C'est un effet secondaire du runtime 2.x, pas un bug dans votre application
- Documentez-le dans vos notes de soumission pour éviter les retards de certification
- Si l'entrée fantôme est inacceptable, le déploiement autonome est la solution la plus propre
Partie de la série Pièges du Store.