Distribuer une application WinUI 3 non empaquetée

La distribution non empaquetée vous permet d’expédier une application WinUI 3 sans MSIX , utile pour les scénarios d’entreprise où le déploiement MSIX n’est pas disponible, ou pour les développeurs qui préfèrent une installation basée sur un dossier traditionnel.

Pour plus d’informations sur toutes les options d’empaquetage, consultez Avantages et inconvénients de l’empaquetage de votre application.

Si vous choisissez de décompresser une application WinUI nouvelle ou existante, procédez comme suit :

<Project ...>
  ...
  <PropertyGroup>
    <WindowsPackageType>None</WindowsPackageType><!-- add this -->
    <OutputType>WinExe</OutputType>
    <TargetFramework>net8.0-windows10.0.19041.0</TargetFramework>
    ...
  </PropertyGroup> 
  ...
</Project>

<Project ...>
  ...
  <PropertyGroup Label="Globals">
    ...
    <AppxPackage>false</AppxPackage><!-- update this -->
    <WindowsPackageType>None</WindowsPackageType><!-- add this -->
    ...
  </PropertyGroup> 
  ...
</Project>

API du programme d'amorçage

La définition de la propriété de projet amène l'auto-initialiseur à localiser et charger une version du SDK d'application Windows qui convient le mieux à votre application.

Si vous avez des besoins avancés (tels que la gestion des erreurs personnalisées ou pour charger une version spécifique du SDK d'application Windows), vous pouvez appeler explicitement l’API du programme d’amorçage. Pour plus d’informations, consultez Utilisez le runtime SDK d'application Windows pour les applications empaquetées avec un emplacement externe ou unpackaged et Tutorial : Utilisez l’API de démarrage dans une application empaquetée avec un emplacement externe ou non empaquetée qui utilise le SDK d'application Windows.

Pour plus d’informations sur le Bootstrapper, consultez Architecture de déploiement et aperçu pour les applications dépendantes du framework.

Déploiement du runtime SDK d'application Windows

Les applications WinUI 3 non empaquetées dépendent du runtime SDK d'application Windows installé sur l'ordinateur de l'utilisateur. Vous disposez de deux options pour vous assurer que le runtime est présent :

Option 1 : SDK d'application Windows programme d’installation du runtime (.exe) (recommandé)

Incluez le programme d’installation SDK d'application Windows runtime en même temps que votre application. Le programme d’installation du runtime est un .exe redistribuable qui installe les packages d’exécution SDK d'application Windows requis. Téléchargez-le à partir de la page des versions du SDK d'application Windows et intégrez-le à votre propre programme d'installation ou script d'installation. Pour obtenir des conseils complets, consultez Utilisez le runtime SDK d'application Windows pour les applications empaquetées avec un emplacement externe ou non empaquetés.

Les utilisateurs doivent exécuter le programme d’installation du runtime une seule fois. Les mises à jour ultérieures de l'application ne nécessitent pas la réinstallation du runtime, sauf si la version requise de SDK d'application Windows change.

Option 2 : Déploiement autonome

Définissez <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained> dans votre fichier projet pour regrouper le runtime SDK d'application Windows directement dans le dossier de sortie de votre application. Cela supprime la dépendance d’exécution : les utilisateurs n’ont pas besoin d’installer quoi que ce soit séparément.

<PropertyGroup>
  <WindowsPackageType>None</WindowsPackageType>
  <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>
</PropertyGroup>

Compromis : votre dossier de sortie est nettement plus grand (l'environnement d'exécution complet est inclus), et chaque mise à jour de l'application comporte l'ensemble du package de l'environnement d'exécution. Utilisez cette option pour les scénarios de distribution simples ou lorsque vous ne pouvez pas contrôler ce qui est installé sur l’ordinateur cible.

→ Déployer des applications non empaquetées qui utilisent le SDK d'application Windows pour obtenir la référence de déploiement d’exécution complète.

Limitation des fichiers EXE uniques

Si une expérience de distribution à fichier unique est importante pour votre scénario, envisagez ces alternatives :

• Utiliser l’empaquetage MSIX : les utilisateurs bénéficient d’une expérience d’installation unique (App Installer gère tous les fichiers) et vous obtenez l’éligibilité du Windows Store, l’identité du package et les mises à jour intégrées
• Utiliser un programme d’installation traditionnel (WiX, Installation d’Inno) : encapsulez le dossier de sortie dans un seul programme d’installation EXE qui extrait et installe tous les fichiers requis de manière transparente.
• Utilisez une autre infrastructure — WPF et les applications WinForms avec dotnet publish --self-contained -p:PublishSingleFile=truecan produisent un exe à fichier unique, bien que certaines dépendances natives puissent toujours être extraites au moment de l’exécution

Considérations relatives à la distribution pour les applications non empaquetées

Les applications WinUI 3 non empaquetées n’ont pas d’identité de package, ce qui signifie qu’elles ne peuvent pas accéder à certaines fonctionnalités de Windows :

• Aucune mise à jour automatique via le programme d’installation d’application ou Windows Store
• Aucune inscription de tâche d'arrière-plan via le manifeste de package
• Il n'y a aucune association de type de fichier ni de gestionnaires de protocole via le manifeste de package.
• Aucune personnalisation de vignette du menu Démarrer via le manifeste du paquet

Si vous avez besoin de ces fonctionnalités, envisagez d’empaqueter avec un emplacement externe comme voie intermédiaire qui ajoute l'identité du package sans nécessiter de conversion MSIX complète.

→ Publier votre première application Windows pour obtenir une vue d’ensemble complète des options de distribution pour WinUI 3 et d’autres infrastructures d’application Windows.