Freigeben über

Aktueller Status der Windows App-Verteilungsfeatures

Diese Seite dokumentiert den aktuellen Status der Windows App-Verteilungsfeatures, die sich geändert haben, bekanntermaßen Einschränkungen aufweisen oder sich anders verhalten, als die Dokumentation vorschlagen kann. Sie wird aktualisiert, wenn sich die Plattform weiterentwickelt.

Zuletzt überprüft: April 2026

ms-appinstaller URI-Protokoll

Status: Standardmäßig deaktiviert (seit Dezember 2023)

Der ms-appinstaller:?source= URI-Protokollhandler ermöglicht es einer Webseite, eine Ein-Klick-App Installer-Installation auszulösen, ohne dass der Benutzer die Datei zuerst herunterladen muss. Dieses Feature wurde standardmäßig in App Installer Version 1.21.3421.0, veröffentlicht am 12. Dezember 2023, als Reaktion auf seinen Missbrauch durch die Emotet-Schadsoftwarekampagne (CVE-2021-43890 Exploitation Pattern) deaktiviert.

Kontext Status
Consumergeräte (Standard) ❌ Deaktiviert
Unternehmensgeräte (verwaltet durch IT) ✅ Kann über Gruppenrichtlinien erneut aktiviert werden

Impact: Lernprogrammseiten auf Microsoft Learn, bei denen <a href="ms-appinstaller:?source=...">Install</a> Weblinks gezeigt werden, funktionieren für die meisten Benutzer nicht mehr.

Problemumgehungen:

  • Link direkt zur .appinstaller Datei – Benutzer laden sie herunter und doppelklicken darauf. Dies funktioniert weiterhin und ist der empfohlene Ansatz für Nicht-Unternehmensszenarien.
  • Veröffentlichung im Microsoft Store bietet eine überlegene Ein-Klick-Installation ohne Protokollabhängigkeit.
  • Erneute Aktivierung von Unternehmen: Legen Sie die Gruppenrichtlinie EnableMSAppInstallerProtocol auf "Aktiviert " über den DesktopAppInstaller-CSP fest. Hinweis: Der Richtlinienwert Disabled bedeutet, dass "die Einstellung nicht konfiguriert ist" (doppelte Verneinung); setzen Sie auf Enabled, um das Protokoll erneut zu aktivieren.

Referenzen:Sicherheitsfeatures des App-Installers

.appinstaller-Dateischemaversionen

Status: Visual Studio generiert standardmäßig veraltetes Schema

Die .appinstaller XML-Datei unterstützt mehrere Schemaversionen mit jeweils unterschiedlichen Funktionen. Visual Studio generiert Dateien standardmäßig mithilfe des Schemas 2017/2, das mehrere wichtige Updatekonfigurationsattribute nicht unterstützt.

Merkmal Schema 2017/2 Schema 2021
ShowPrompt ❌ Nicht unterstützt ✅ Unterstützt
UpdateBlocksActivation ❌ Nicht unterstützt ✅ Unterstützt
HoursBetweenUpdateChecks ❌ Nicht unterstützt ✅ Unterstützt
Grundlegendes Update beim Start ✅ Unterstützt ✅ Unterstützt

Impact: Entwickler, die auf Visual Studio angewiesen sind, um .appinstaller Dateien zu generieren und anschließend ShowPrompt oder UpdateBlocksActivation zu konfigurieren, werden feststellen, dass diese Einstellungen zur Laufzeit stillschweigend ignoriert werden.

Lösung: Manuelles Aktualisieren des xmlns Attribut in der .appinstaller Datei.

<!-- Change this: -->
<AppInstaller xmlns="http://schemas.microsoft.com/appx/appinstaller/2017/2" ...>

<!-- To this: -->
<AppInstaller xmlns="http://schemas.microsoft.com/appx/appinstaller/2021" ...>

Referenzen:Automatisch aktualisieren und reparieren Apps · WindowsAppSDK Diskussion #5125

SmartScreen-Zuverlässigkeit: EV-Zertifikate gewähren keine sofortige Umgehung mehr

Status: Verhalten geändert im Jahr 2024

Vor 2024 erhielten Codesignaturzertifikate für die erweiterte Validierung (Extended Validation, EV) sofort SmartScreen-Reputation – eine neu signierte Binärdatei zeigt keine Download-Warnung an. Microsoft hat die Anforderungen des vertrauenswürdigen Stammprogramms im Jahr 2024 aktualisiert und EV-spezifische OIDs entfernt. SmartScreen-Reputation ist jetzt ausschließlich hashbasiert und akkumuliert sich im Laufe der Zeit, unabhängig vom Zertifikattyp (OV oder EV).

Auswirkungen: Entwickler, die EV-Zertifikate speziell erworben haben, um SmartScreen-Warnungen für neue Versionen zu umgehen, stellen fest, dass EV-Zertifikate diesen Vorteil nicht mehr bieten.

Aktuelles Verhalten: Alle nicht aus dem Store stammenden und nicht von Microsoft signierten Binärdateien zeigen beim ersten Herunterladen eine SmartScreen-Eingabeaufforderung an, bis ausreichend Downloadverlauf für diesen Dateihash gesammelt wurde.

Ausführliche Informationen zu erwarteten Verhaltensweisen und Empfehlungen finden Sie unter SmartScreen-Reputation für Windows App-Entwickler.

MSIX auf Windows 10 vs Windows 11

Status: Mehrere MSIX-Features sind Windows 11-only

MSIX funktioniert sowohl für Windows 10 als auch für Windows 11, aber mehrere Features – einschließlich freigegebener Paketcontainer, veränderbarer Paketverzeichnisse und MSIX persistenter Identität – sind Windows 11-only und wurden nicht zurückportiert. Dynamische Abhängigkeiten werden unter Windows 10 auch über das Windows App SDK (Mdd*-APIs / Bootstrapper) unterstützt, während Windows 11 zusätzlich eine systemeigene Betriebssystemimplementierung bietet. Darüber hinaus endete Windows 10 Mainstream-Support am 14. Oktober 2025.

Eine vollständige Vergleichstabelle, bekannte unbackportierte Einschränkungen und Problemumgehungen pro Feature finden Sie unter MSIX für Windows 10 und Windows 11.

MsixPackaging@1 Azure DevOps Aufgabe

Status: Verwendet veraltete Abhängigkeiten

Der vorgang MsixPackaging@1 in Azure DevOps Pipelines verwendet MSBuild 4.8.4161.0 (anstelle von MSBuild 16+) und wurde gegen Node 16 erstellt (das im September 2023 das Ende der Lebensdauer erreicht hat). Dies kann zu Buildfehlern in modernen Pipelinekonfigurationen führen.

Workaround: Verwenden Sie MSBuild direkt in Ihrer Pipeline anstelle der aufgabe MsixPackaging@1, oder verwenden Sie GitHub Actions mit der Aktion microsoft/setup-msbuild.

References:GitHub Problem #518 · GitHub Problem #679

Verwandte Inhalte

  • Last updated on