Connaître votre programme d’installation

Cet article répertorie les éléments à connaître avant de convertir votre programme d’installation existant en MSIX. Vous n’avez peut-être pas à faire beaucoup pour préparer votre application pour le processus d’empaquetage, mais si l’un des éléments ci-dessous s’applique à votre application, vous devez l’aborder avant l’empaquetage.

• Votre application a un service. Nous prenons en charge la conversion d’applications avec des services, mais il est important de garder à l’esprit les limitations de conversion d’un service. Après la conversion, vous aurez besoin d’une élévation d’administrateur pour installer msIX qui contient un service. Vous pouvez convertir une application avec des services à partir de la version 1.2019.1220.0 de MSIX Packaging Tool, et vous pouvez déployer MSIX avec des services à partir du printemps 2020 de Windows 10.

• Votre programme d’installation nécessite un redémarrage. Si votre programme d’installation nécessite un redémarrage, il est pris en charge dans msIX Packaging Tool à compter de la version 1.2019.701.0. Si votre programme d’installation retourne un code de sortie rare pour indiquer qu’il a besoin d’un redémarrage, vous devez l’ajouter à la section codes de sortie de redémarrage des paramètres de l’outil d’empaquetage MSIX.

• Votre application .NET nécessite une version du .NET Framework antérieure à la version 4.6.2. Si vous empaquetez une application .NET, nous vous recommandons de cibler .NET Framework 4.6.2 ou une version ultérieure. La possibilité d’installer et d’exécuter des applications de bureau empaquetées a été introduite pour la première fois dans Windows 10, version 1607 (également appelée mise à jour anniversaire), et cette version du système d’exploitation inclut le .NET Framework 4.6.2 par défaut. Les versions ultérieures du système d’exploitation incluent les versions ultérieures du .NET Framework. Pour obtenir la liste complète des versions de .NET incluses dans les versions ultérieures de Windows 10, consultez cet article.

  Le ciblage des versions du .NET Framework antérieures à la version 4.6.2 dans les applications de bureau empaquetées devrait fonctionner dans la plupart des cas. Toutefois, si vous ciblez une version antérieure à la version 4.6.2, vous devez tester entièrement votre application de bureau empaquetée avant de la distribuer aux utilisateurs.

  • 4.0 - 4.6.1 : Les applications qui ciblent ces versions du .NET Framework sont censées s’exécuter sans problème sur la version 4.6.2 ou ultérieure. Par conséquent, ces applications doivent installer et s’exécuter sans modification sur Windows 10, version 1607 ou ultérieure avec la version du .NET Framework incluse dans le système d’exploitation.

  • 2.0 et 3.5 : Dans nos tests, les applications de bureau empaquetées qui ciblent ces versions du .NET Framework fonctionnent généralement, mais peuvent présenter des problèmes de performances dans certains scénarios. Pour que ces applications empaquetées s’installent et s’exécutent, la fonctionnalité .NET Framework 3.5 doit être installée sur l’ordinateur cible (cette fonctionnalité inclut également .NET Framework 2.0 et 3.0). Vous devez également tester ces applications soigneusement après leur empaquetage.

• Votre application nécessite un pilote. MSIX ne prend pas en charge les pilotes.

• Votre application écrit dans le dossier AppData ou dans le Registre avec l’intention de partager des données avec une autre application. Après la conversion, AppData est redirigé vers le magasin de données d’application local, qui est un magasin privé pour chaque application.

  Toutes les entrées que votre application écrit dans la ruche de Registre HKEY_LOCAL_MACHINE sont redirigées vers un fichier binaire isolé et toutes les entrées que votre application écrit dans la ruche de registre HKEY_CURRENT_USER sont placées dans un emplacement privé par utilisateur et par application. Pour plus d’informations sur la redirection de fichiers et de registre, consultez Behind the scenes of the Desktop Bridge.

• Votre application écrit dans le répertoire d’installation de votre application. Par exemple, votre application écrit dans un fichier journal que vous avez placé dans le même répertoire que votre exe. Cela n’est pas pris en charge, car le dossier est protégé. Nous vous recommandons d’écrire dans un autre emplacement comme le magasin de données d’application local. Nous avons ajouté une fonctionnalité qui permet cela en 1809 et versions ultérieures.

• Votre application utilise le répertoire de travail actuel. Au moment de l’exécution, votre application de bureau empaquetée n’obtient pas le même répertoire de travail que celui que vous avez spécifié précédemment dans votre bureau. Raccourci LNK. Vous devez modifier votre CWD au moment de l’exécution si le répertoire approprié est important pour que votre application fonctionne correctement.

• Votre application installe et charge des assemblies à partir du dossier Windows côte-à-côte. Par exemple, votre application utilise des bibliothèques de runtime C VC8 ou VC9 et les lie dynamiquement à partir du dossier côte à côte Windows, ce qui signifie que votre code utilise les fichiers DLL courants à partir d’un dossier partagé, tel que C :\Windows\WinSxS. Cela n'est pas pris en charge. Vous devez les lier statiquement en les liant directement aux fichiers de bibliothèque redistribuables dans votre code.

Autres considérations

• Réempaqueter votre programme d'installation sur l’architecture aproppriée. Si votre programme d’installation est destiné à être installé sur un ordinateur x86. Veillez à repackager votre programme d’installation sur un ordinateur x86. Cela s’applique au programme d’installation destiné aux machines x64.

  Remarque

  Si votre application doit écrire dans le répertoire d’installation ou utiliser le répertoire de travail actuel, vous pouvez également envisager d’ajouter un correctif d’exécution à l’aide du Package Support Framework à votre package. Pour plus d’informations, consultez cet article.