État actuel des fonctionnalités de distribution d’applications Windows

Cette page documente l’état actuel des fonctionnalités de distribution des applications Windows qui ont changé, présentent des limitations connues, ou se comportent différemment de ce que leur documentation pourrait suggérer. Elle est mise à jour à mesure que la plateforme évolue.

Dernière révision : Avril 2026

protocole d’URI ms-appinstaller

État : Désactivé par défaut (depuis décembre 2023)

Le ms-appinstaller:?source= gestionnaire de protocole URI permet à une page web de déclencher l’installation d’un programme d’installation d’application en un clic sans que l’utilisateur télécharge le fichier en premier. Cette fonctionnalité a été désactivée par défaut dans App Installer version 1.21.3421.0, publiée le 12 décembre 2023, en réponse à son abus par la campagne de programmes malveillants Emotet (modèle d’exploitation CVE-2021-43890).

Contexte État
Appareils grand public (par défaut) ❌ Handicapés
Appareils d’entreprise (gérés par l’informatique) ✅ Peut être réactivé via la stratégie de groupe

Impact : Pages didacticiels sur Microsoft Learn qui démontrent des <a href="ms-appinstaller:?source=...">Install</a> liens web ne fonctionnent plus pour la plupart des utilisateurs.

Solutions de contournement :

  • Relier directement au .appinstaller fichier — les utilisateurs le téléchargent et double-cliquent dessus. Cela fonctionne toujours et est l’approche recommandée pour les scénarios non-entreprise.
  • Publish sur le Microsoft Store : offre une expérience d’installation en un clic supérieure sans dépendance de protocole.
  • Réactivation des fonctionnalités d'entreprise : Définissez la stratégie de groupe EnableMSAppInstallerProtocol sur Activé via le CSP DesktopAppInstaller. Remarque : la valeur de la stratégie Disabled signifie que « le paramètre n’est pas configuré » (double négatif); définir sur Enabled pour réactiver le protocole.

Références :Fonctionnalités de sécurité du programme d’installation d’application

Versions du schéma de fichier .appinstaller

Status : Visual Studio génère un schéma obsolète par défaut

Le .appinstaller fichier XML prend en charge plusieurs versions de schéma, chacune avec des fonctionnalités différentes. Visual Studio génère des fichiers à l’aide du schéma 2017/2 par défaut, qui ne prend pas en charge plusieurs attributs de configuration de mise à jour importants.

Caractéristique Schéma 2017/2 Schéma 2021
ShowPrompt ❌ Non pris en charge ✅ Supporté
UpdateBlocksActivation ❌ Non pris en charge ✅ Supporté
HoursBetweenUpdateChecks ❌ Non pris en charge ✅ Supporté
Mise à jour de base lors du lancement ✅ Supporté ✅ Supporté

Impact : Développeurs qui s’appuient sur Visual Studio pour générer des fichiers .appinstaller, puis configurer ShowPrompt ou UpdateBlocksActivation trouve que ces paramètres sont ignorés silencieusement lors de l’exécution.

Correction: Mettez à jour manuellement l’attribut xmlns dans le fichier .appinstaller :

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

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

Références :Mise à jour automatique et réparation d’applications · Discussion WindowsAppSDK #5125

Réputation SmartScreen : les certificats EV n’accordent plus de passage instantané.

État : Comportement modifié en 2024

Avant 2024, les certificats de signature de code de validation étendue (EV) ont accordé une réputation immédiate SmartScreen. Un binaire nouvellement signé ne montrait aucun avertissement de téléchargement. Microsoft a mis à jour les exigences du Programme racine de confiance, supprimant les OID spécifiques à l'EV en 2024. La réputation de SmartScreen est désormais exclusivement basée sur le hachage et s’accumule au fil du temps, quel que soit le type de certificat (OV ou EV).

Impact: Les développeurs qui ont acheté des certificats EV spécifiquement pour contourner les avertissements SmartScreen pour les nouvelles versions trouveront que les certificats EV ne fournissent plus cet avantage.

Comportement actuel : Tous les binaires non signés par Microsoft ou ne provenant pas du Store affichent une invite SmartScreen lors du premier téléchargement jusqu’à ce qu’un historique de téléchargement suffisant ait été accumulé pour le hachage de ce fichier.

Consultez la réputation SmartScreen pour les développeurs d’applications Windows pour obtenir des détails complets sur le comportement et les recommandations attendus.

MSIX sur Windows 10 et Windows 11

Status : plusieurs fonctionnalités MSIX sont Windows 11 uniquement

MSIX fonctionne à la fois sur Windows 10 et sur Windows 11, mais plusieurs fonctionnalités, notamment les conteneurs de packages partagés, les répertoires de package mutables et l’identité persistante MSIX, sont Windows 11 uniquement et n’ont pas été rétroportées. Les dépendances dynamiques sont également prises en charge sur Windows 10 via le SDK d'application Windows (Mdd* API / bootstrapper), Windows 11 fournissant en outre une implémentation native du système d’exploitation. En outre, Windows 10 support standard a pris fin le 14 octobre 2025.

Pour obtenir une table de comparaison complète, des limitations non rétroportées connues et des solutions de contournement par fonctionnalité, consultez MSIX sur Windows 10 et Windows 11.

tâche MsixPackaging@1 dans Azure DevOps

État : utilise des dépendances obsolètes

La tâche MsixPackaging@1 dans Azure DevOps pipelines utilise MSBuild 4.8.4161.0 (au lieu de MSBuild 16+) et a été générée sur Node 16 (qui a atteint la fin de vie en septembre 2023). Cela peut entraîner des défaillances de build dans les configurations de pipeline modernes.

Workaround : Utilisez MSBuild directement dans votre pipeline plutôt que la tâche MsixPackaging@1, ou utilisez GitHub Actions avec l’action microsoft/setup-msbuild.

References :GitHub Problème #518 · GitHub Problème #679

Contenu connexe

  • Last updated on