Guide de déploiement du Kit de développement logiciel (SDK) d’application Windows pour les applications autonomes

Un projet sdk d’application Windows dépend de l’infrastructure par défaut. Pour passer au déploiement autonome, suivez les étapes ci-dessous (les termes dépendant de l’infrastructure et autonome sont décrits dans la vue d’ensemble du déploiement du Kit de développement logiciel (SDK) d’application Windows).

  • Dans Visual Studio, cliquez avec le bouton droit sur le nœud du projet d’application, puis cliquez sur Modifier le fichier projet pour ouvrir le fichier projet d’application à modifier. Pour un projet C++, cliquez d'abord sur Décharger le Projet.
  • Dans le fichier projet d’application, à l’intérieur du fichier principal PropertyGroup, ajoutez <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained> comme indiqué dans la capture d’écran ci-dessous.

Capture d’écran montrant la propriété WindowsAppSDKSelfContained définie dans un fichier projet.

  • Enregistrez et fermez le fichier projet.
  • Cliquez sur Recharger le projet.
  • Si vous utilisez un projet de création de packages d'applications Windows (plutôt que le projet MSIX à projet unique que vous obtenez avec l’application vide WinUI (empaqueté)), apportez également toutes les modifications ci-dessus dans le fichier projet de package pour le projet d’empaquetage.

Remarque

Les projets de bibliothèque ne doivent pas être modifiés. Le déploiement autonome ne doit être configuré que dans les projets d’application (et, le cas échéant, dans un projet d’empaquetage d’applications Windows).

Pour obtenir des exemples d’applications, consultez les exemples de déploiement autonome du Kit de développement logiciel (SDK) d’application Windows.

Après avoir défini la propriété WindowsAppSDKSelfContained property to true dans votre fichier de projet, le contenu du package Framework du SDK d'application Windows s'extraira dans le répertoire de sortie de votre build et sera déployé dans le cadre de votre application.

Remarque

Les applications .NET doivent être publiées comme autonomes et être entièrement autonomes. Consultez cet exemple pour savoir comment configurer .NET comme autonome avec des profils de publication.

Notez que dotnet publish regroupe des assemblys managés, mais ne produit pas un fichier EXE pour les applications WinUI 3 : les dépendances natives SDK d'application Windows runtime doivent rester sous forme de fichiers distincts. Pour plus d’informations, consultez EXE à fichier unique .

Remarque

Les applications C++ doivent également utiliser les CRT hybrides et être entièrement autonomes. L’importation de HybridCRT.props à partir de Directory.Build.props est la méthode recommandée pour la configurer pour tous les projets d’une solution (voir un exemple dans Directory.Build.props). Une application empaquetée doit également définir <UseCrtSDKReferenceStaticWarning>false</UseCrtSDKReferenceStaticWarning> dans son fichier de projet. Consultez l'exemple d'application de déploiement autonome pour savoir comment utiliser le CRT hybride.

Si votre application est empaquetée (pour plus d’informations, consultez Vue d’ensemble de l’empaquetage et du déploiement), les dépendances SDK d'application Windows seront incluses en tant que contenu dans le package MSIX. Le déploiement de l’application nécessite toujours l’inscription du package MSIX comme toute autre application empaquetée.

Si votre application est packagée avec un emplacement externe ou non packagée, les dépendances du SDK d’application Windows sont copiées à côté de .exe dans votre sortie de build. Vous pouvez déployer les fichiers résultants à l'aide de la méthode xcopy, ou les inclure dans un programme d’installation personnalisé.

Dépendances sur des packages MSIX supplémentaires

Un petit nombre d’API dans le Kit de développement logiciel (SDK) d’application Windows reposent sur des packages MSIX supplémentaires qui représentent des fonctionnalités de système d’exploitation critiques.

Pour utiliser des API qui dépendent de packages MSIX supplémentaires dans une application autonome, vous disposez des options suivantes :

  1. Vous pouvez rendre votre fonctionnalité facultative et l’allumer uniquement si possible. L’appel de la méthode IsSupported des API (PushNotificationManager.IsSupported) vous permet de vérifier dynamiquement au moment de l’exécution si les API sont disponibles ou non pour l’application appelante sur le système sur lequel elle s’exécute.
    • Cela permet une utilisation sécurisée, conditionnelle et facultative des API sans compromettre la simplicité de votre déploiement autonome.
    • Uniquement si les services de système d’exploitation sont installés en dehors de votre déploiement d’application, votre application allume les fonctionnalités appropriées. Toutefois, il existe certains cas où les API fonctionnent même sans que le package Singleton soit présent ; Ainsi, l’appel de IsSupported à vérifier est souvent une bonne idée.
  2. Déployez les packages MSIX requis dans le cadre de l’installation de votre application.
    • Cela vous permet de dépendre de l’API dans tous les scénarios. Cependant, exiger le déploiement d’un package MSIX de dépendances dans le cadre du déploiement de votre application peut compromettre la simplicité d’un déploiement autonome.
  3. N’utilisez pas l’API.
    • Envisagez d’autres API qui fournissent des fonctionnalités similaires sans exigences de déploiement supplémentaires.

Refus ou acceptation de la prise en charge automatique UndockedRegFreeWinRT

La propriété de projet WindowsAppSdkUndockedRegFreeWinRTInitialize contrôle si l’implémentation par le SDK d’application Windows du Windows Runtime sans inscription et non ancré (UndockedRegFreeWinRT) est activée automatiquement lors du démarrage de l’application. Les applications autonomes non empaquetées nécessitent ce support.

WindowsAppSdkUndockedRegFreeWinRTInitialize a la valeur true si WindowsAppSDKSelfContained a la valeur true et que la propriété du projet WindowsPackageType est None et OutputType a la valeur Exe ou WinExe (autrement dit, le projet produit un exécutable). Cette dernière condition empêche l’ajout de la prise en charge automatique de UndockedRegFreeWinRT dans les DLL de bibliothèque de classes et d’autres fichiers non exécutables par défaut. Si vous avez besoin de la prise en charge automatique d’UndockedRegFreeWinRT dans un fichier non exécutable (par exemple, une DLL de test chargée par un processus hôte exécutable qui n’initialise pas UndockedRegFreeWinRT), vous pouvez l’activer explicitement dans votre projet avec <WindowsAppSdkUndockedRegFreeWinRTInitialize>true</WindowsAppSdkUndockedRegFreeWinRTInitialize>.

  • Dernière mise à jour :