Vue d’ensemble du déploiement SDK d'application Windows

Il existe deux façons de déployer le SDK d'application Windows :

  • dépendant du framework. Votre application dépend du SDK d'application Windows runtime et/ou du package Framework présents sur l’ordinateur cible. Le déploiement dépendant de l’infrastructure est le mode de déploiement par défaut de l’SDK d'application Windows pour son utilisation efficace des ressources de machine et de la facilité de service.
  • autonome . Votre application comporte les dépendances SDK d'application Windows avec elle, ce qui élimine la nécessité d’une installation d’exécution distincte sur l’ordinateur cible.

Cette rubrique utilise également les termes de l’application empaquetée, de l’application empaquetée avec un emplacement externe et de l’application non empaquetée. Pour obtenir des explications sur ces termes, consultez la vue d’ensemble du déploiement.

Déployer en fonction du cadre Déployer module autonome
Avantages Petit déploiement. Seule votre application et ses autres dépendances sont distribuées. Le SDK d'application Windows runtime et le package Framework sont installés automatiquement par des applications dépendantes de l’infrastructure qui sont empaquetées ; ou dans le cadre du programme d’installation d’SDK d'application Windows runtime par des applications dépendantes de l’infrastructure qui sont empaquetées avec un emplacement externe ou non empaquetées.

En état de fonctionnement. Les mises à jour de maintenance des SDK d'application Windows sont installées automatiquement via le package SDK d'application Windows Framework sans aucune action requise de l’application.		 Contrôler la version du SDK Windows App. Vous contrôlez la version du SDK d'application Windows déployée avec votre application. La maintenance des mises à jour du SDK d'application Windows n'impacte pas votre application, sauf si vous régénérez et redistribuez-la.

Isolé d’autres applications. Les applications et les utilisateurs ne peuvent pas désinstaller votre dépendance SDK d'application Windows sans désinstaller l'ensemble de votre application.

Déploiement Xcopy. Étant donné que les dépendances du SDK d'application Windows sont incluses dans votre application, vous pouvez déployer votre application en copiant simplement les fichiers générés lors de la compilation, sans nécessiter de configuration d'installation supplémentaire.
Inconvénients Dépendances d’installation supplémentaires. Nécessite l’installation du package SDK d'application Windows runtime et/ou Framework, ce qui peut ajouter de la complexité à l’installation de l’application.

Dépendances partagées. Risque que les dépendances partagées soient désinstallées. Les applications ou les utilisateurs qui désinstallent les composants partagés peuvent avoir un impact sur l’expérience utilisateur d’autres applications qui partagent la dépendance.

Risque de compatibilité. Risque que les mises à jour de maintenance du SDK d'application Windows introduisent des modifications rompant la compatibilité. Bien que les mises à jour de maintenance fournissent une compatibilité descendante, il est possible que les régressions soient introduites.		 Déploiements plus volumineux (applications non empaquetées uniquement). Étant donné que votre application inclut le SDK d'application Windows, la taille de téléchargement et l’espace disque requis sont supérieurs à ce qui serait le cas pour une version dépendante du framework.

Performances (applications non empaquetées uniquement). Plus lent à charger et utilise plus de mémoire, car les pages de code ne sont pas partagées avec d’autres applications.

Non réparable. La version SDK d'application Windows distribuée avec votre application ne peut être mise à jour qu’en publiant une nouvelle version de votre application. Vous êtes responsable de l'intégration des mises à jour de maintenance des SDK d'application Windows dans votre application.

Consultez également Créer votre premier projet WinUI 3 et Utiliser le SDK d'application Windows dans un projet existant.

Remarque

PublishSingleFile (EXE à fichier unique) est pris en charge pour les applications WinUI 3 non empaquetées et autonomes (SDK d'application Windows 1.5 et versions ultérieures). Les applications empaquetées et les applications dépendantes du framework ne prennent pas en charge PublishSingleFile. Consultez EXE à fichier unique pour connaître les propriétés MSBuild requises.

Plus d’informations sur le déploiement dépendant du framework

Avant de configurer votre application dépendante de l’infrastructure pour le déploiement, pour en savoir plus sur les dépendances que votre application utilise quand elle utilise le SDK d'application Windows, passez en revue l’architecture Déploiement pour l’architecture SDK d'application Windows.

Applications empaquetées

Si vous avez choisi d'utiliser une application empaquetée dépendante du framework (consultez Vue d'ensemble du déploiement), voici des instructions sur le déploiement du runtime SDK d'application Windows avec l'application :

Fournis avec un emplacement externe ou des applications non empaquetées

Si vous avez choisi d'utiliser une application empaquetée dépendante du framework avec un emplacement externe ou une application non empaquetée dépendante de l'infrastructure (voir Vue d'ensemble du déploiement), voici des instructions sur le déploiement du runtime SDK d'application Windows avec l'application :

Plus d’informations sur le déploiement autonome

Consultez SDK d'application Windows guide de déploiement pour les applications autonomes.

Remarque

PublishSingleFile (EXE à fichier unique) nécessite que l’application soit à la fois non empaquetée et autonome. Consultez EXE à fichier unique pour obtenir la liste complète des propriétés MSBuild requises.

Initialiser le SDK d'application Windows

La façon dont vous devez initialiser l’SDK d'application Windows dépend de la façon dont vous empaquetez votre application et de la façon dont vous déployez par rapport au runtime SDK d'application Windows. Utilisez la section ci-dessous qui s’applique à votre application.

Applications empaquetées

Comment votre application est déployée Comment initialiser
Dépendant du cadre Consultez et appelez l’API de Déploiement.
Indépendant Aucune initialisation n’est nécessaire.

Applications non empaquetées et applications empaquetées avec un emplacement externe

Comment votre application est déployée Comment initialiser
Dépendant du cadre Consultez Utiliser l'API bootstrapper dans une application empaquetée avec un emplacement externe ou non empaquetée.
Indépendant Consultez pour vous désinscrire de (ou vous inscrire à) la prise en charge automatique de UndockedRegFreeWinRT.

Considérations relatives à l’architecture (x64, ARM64)

Lorsque vous déployez votre application, vous devez inclure des fichiers binaires pour chaque architecture de processeur dont vos utilisateurs ont besoin. Cela s’applique aux modes de déploiement dépendants du framework et autonomes.

Prise en charge d’ARM64

Les appareils Windows on ARM (y compris Surface Pro X, Surface Pro 11 et les PC Copilot+) exécutent ARM64 nativement. Bien que l’émulation x64 soit disponible sur les appareils ARM64 sous Windows 11, les binaires ARM64 natifs offrent de meilleures performances et une meilleure autonomie, et sont recommandés si vous recherchez la meilleure expérience pour les charges de travail d’IA exécutées sur l’appareil sur les PC Copilot+.

Déploiement ARM64 natif

  • Bundles MSIX — Créez un .msixbundle qui inclut les architectures x64 et ARM64. Visual Studio génère ces éléments automatiquement lorsque vous générez pour plusieurs plateformes. Le Windows Store et le programme d’installation d’application sélectionnent l’architecture appropriée au moment de l’installation.

  • Publication autonome : spécifiez l’identificateur d’exécution (RID) pour chaque architecture :

    dotnet publish -c Release -r win-x64 --self-contained true
dotnet publish -c Release -r win-arm64 --self-contained true

  • C++/WinRT : créez des configurations distinctes pour x64 et ARM64 dans votre solution Visual Studio.

  • Applications dépendantes de l’infrastructure : lors de l’utilisation du programme d’installation du runtime SDK d'application Windows, assurez-vous de fournir le programme d’installation spécifique à l’architecture approprié. Le SDK d'application Windows fournit des programmes d’installation distincts pour x64 et ARM64.

Arm64EC : migration progressive pour les bases de code C/C++ volumineuses

Si votre application a une base de code native volumineuse (C/C++), une recompilation complète en ARM64 peut ne pas être pratique en une seule étape. Arm64EC (Compatible émulation) vous permet de combiner du code x64 et ARM64 dans le même processus. Vous recompilez les modules critiques en termes de performances en ARM64 natif, tandis que les modules x64 restants s’exécutent sous émulation, dans un seul binaire.

Approche Idéal pour Compromis
Recompilation ARM64 complète Applications pures .NET, petits projets C++ Performances optimales ; nécessite que toutes les dépendances soient compatibles avec ARM64
Arm64EC Applications C/C++ volumineuses, applications avec des plug-ins x64 uniquement ou des DLL tierces Migration incrémentielle; les portions émulées s’exécutent plus lentement que les portions natives
x64 uniquement (émulé) Applications qui ne peuvent pas être recompilées et n’ont pas besoin de performances optimales Le plus simple ; réduction de la durée de vie de la batterie et latence plus élevée sur les appareils ARM64

Pour plus d’informations, consultez Arm64EC — Générer et porter des applications pour des performances natives sur Arm.

Émulation (Prism)

Windows 11 sur ARM utilise une couche d’émulation appelée Prism pour exécuter des applications x64 et x86 sur du matériel ARM64. Prism traduit des instructions x86/x64 en ARM64 au moment de l’exécution, fournissant une compatibilité étendue des applications sans nécessiter de recompilation.

  • Émulation x64 : disponible sur Windows 11 appareils ARM64 uniquement (pas Windows 10 sur ARM).
  • Émulation x86 : disponible sur les appareils Windows 10 et Windows 11 ARM64.
  • Performances : les applications émulées s’exécutent généralement avec des performances acceptables pour les charges de travail de productivité, mais les applications gourmandes en graphiques ou lourdes de calcul bénéficient considérablement d’une build ARM64 ou Arm64EC native.

Tip

Si vous ciblez uniquement x64, votre application s’exécute toujours sur des appareils ARM64 via l’émulation Prism (Windows 11 uniquement). Toutefois, les builds ARM64 natives sont fortement recommandées pour les applications de production : les applications émulées utilisent davantage de batterie et ont une latence plus élevée. Sur Copilot+ PCs, ARM64 natif peut fournir les meilleures performances pour les charges de travail IA sur appareil.

Pour les soumissions du Windows Store, chargez des packages spécifiques à l’architecture ou un bundle contenant les deux. Le Windows Store fournit uniquement l’architecture correspondante à chaque appareil.

  • Last updated on