Store-Fallen #1: Die Abhängigkeit meiner App hat einen Geister-Eintrag im Startmenü erzeugt
2026-05-28
Tags: Windows · MSIX · Microsoft Store · Store-Fallen
Windows-Apps im Microsoft Store zu veröffentlichen, ist nicht immer reibungslos. Diese Serie dokumentiert die echten Fallstricke, die ich erlebt habe — einer pro Beitrag, kurz und praxisnah.
Hier ist der erste.
Hintergrund
RDP Heartbeat begann als Python-+ Tkinter-Werkzeug — ein kleiner atmender Punkt, der anzeigt, ob Ihre RDP-Sitzung noch aktiv ist. Es funktionierte, aber eine Python-Desktop-App für den Microsoft Store zu verpacken, war ein Abenteuer: Python-Quellcode → PyInstaller-Exe → Inno-Setup-Installer → MSIX-Paket. Wir haben die ganze Reise in einem Artikel beschrieben.
Also habe ich es komplett neu in nativem WinUI 3 mit Windows App SDK 2.0.1 geschrieben. Der native Weg sollte reibungslos verlaufen — kein Python-Verpackungs-Akrobatik mehr. Und das war er auch, bis zur Store-Zertifizierung.
"Bestanden mit erforderlicher Korrektur"
Das Zertifizierungsergebnis kam zurück:
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.
Bestanden — aber mit einer Warnung. Etwas Zusätzliches war im Startmenü aufgetaucht, und es war nicht meine App.
Der Geister-Eintrag
Der Zertifizierungsbericht besagte, dass etwas Zusätzliches im Startmenü erschienen war. Ich sah nach — und ganz ehrlich, nichts Ungewöhnliches. Mein Startmenü sah genau wie erwartet aus, keine zusätzlichen Kacheln.
Ich habe das gesamte Projekt durchgesehen: das Paketmanifest geprüft, die Build-Ausgabe angesehen, mit meinen anderen Store-Apps verglichen. Keine zusätzlichen Pakete, keine verdächtigen Erweiterungen, nichts fiel auf.
Aber es gab einen Unterschied. Meine anderen Apps — EnvStudio, GhostWin, QuickGUID — verwenden alle Windows App SDK 1.8.x. RDP Heartbeat ist die einzige App mit SDK 2.0.1. Das ist die einzige Variable, die sich geändert hat.
WinUI 3-Apps hängen von der Windows App SDK-Laufzeitumgebung ab, die als MSIX-Pakete verteilt und als gemeinsame Systemabhängigkeiten installiert wird. Der einzige Verdächtige, den ich ausmachen kann, ist die SDK 2.x-Laufzeit — irgendwie erzeugt ihre Bereitstellung auf Microsofts Testumgebung (aber nicht auf meinem Rechner) eine sichtbare Startmenü-Kachel. Warum genau, weiß ich nicht.
Was können Sie dagegen tun?
Hier ist der frustrierende Teil: Sie können es nicht direkt beheben. Die Laufzeitpakete werden von Microsoft erstellt — Sie haben keine Kontrolle darüber, wie sie im Startmenü erscheinen.
Ihre praktischen Optionen:
- Akzeptieren und dokumentieren — Fügen Sie Ihrer Store-Einreichung einen Hinweis hinzu, der erklärt, dass die zusätzliche Kachel eine von Microsoft bereitgestellte Laufzeitabhängigkeit und kein separates Produkt ist. Das habe ich getan, und die Zertifizierung wurde bestanden.
- Auf eigenständige Bereitstellung umsteigen — Bündeln Sie die Laufzeit direkt in Ihr App-Paket, indem Sie
<WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>in Ihrer.csproj-Datei setzen. Dies eliminiert die DEPN vollständig, erhöht aber die Download-Größe um ca. 40 MB pro Architektur.
Das Fazit
Wenn Sie mit Windows App SDK 2.x für den Microsoft Store entwickeln:
- Seien Sie sich bewusst, dass die Laufzeitabhängigkeit eine sichtbare Startmenü-Kachel erzeugen kann
- Es ist eine Nebenwirkung der 2.x-Laufzeit, kein Fehler in Ihrer App
- Dokumentieren Sie es in Ihren Einreichungsnotizen, um Zertifizierungsverzögerungen zu vermeiden
- Wenn der Geister-Eintrag inakzeptabel ist, ist die eigenständige Bereitstellung die sauberste Lösung
Teil der Store-Fallen-Serie.