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 de .NET Framework antérieure à la version 4.6.2. Si vous créez le package d’une application .NET, votre application a intérêt à cibler .NET Framework 4.6.2 ou ultérieur. La possibilité d’installer et d’exécuter des applications de bureau packagées a été introduite pour la première fois dans Windows 10, version 1607 (également appelée Mise à jour anniversaire). Cette version du système d’exploitation comprend .NET Framework 4.6.2 par défaut. Les versions ultérieures du système d’exploitation incluent des 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.

  Dans la plupart des cas, cibler des versions de .NET Framework antérieures à 4.6.2 dans des applications de bureau packagées est supposé fonctionner. En revanche, si vous ciblez une version antérieure à 4.6.2, vous devez tester entièrement votre application de bureau packagée avant de la distribuer aux utilisateurs.

  • 4.0 à 4.6.1 : les applications qui ciblent ces versions de .NET Framework sont censées s’exécuter sans problème sur la version 4.6.2 ou ultérieure. Ainsi, ces applications s’installent et s’exécutent 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 le cadre de nos tests, les applications de bureau packagées qui ciblent ces versions du .NET Framework fonctionnent globalement, mais peuvent être sujettes à des problèmes de performances dans certains scénarios. Pour que ces applications packagées s’installent et s’exécutent, la fonctionnalité .NET Framework 3.5 doit être installée sur l’ordinateur cible (cette fonctionnalité comprend également .NET Framework 2.0 et 3.0). Vous devez également tester ces applications minutieusement après les avoir packagées.

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

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

  Toutes les entrées écrites par votre application dans la ruche du Registre HKEY_LOCAL_MACHINE sont redirigées vers un fichier binaire isolé et toutes les entrées écrites par votre application dans la ruche du 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 du Registre, consultez Fonctionnement détaillé de Pont du bureau.

• 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 fichier 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. Lors de l’exécution, votre application de bureau empaquetée ne dispose pas du même répertoire de travail que celui spécifié précédemment dans le raccourci .LNK sur votre bureau. Vous devez modifier votre répertoire de travail actuel lors de l’exécution si le fait de disposer du répertoire correct est important pour le bon fonctionnement de votre application.

• Votre application installe et charge des assemblys à 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

• Repackaging your installer on the proper architecture. 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 a besoin d’écrire dans le répertoire d’installation ou d’utiliser le répertoire de travail actuel, vous pouvez également envisager d’ajouter une correction du runtime à votre package à l’aide du Framework de prise en charge de package. Pour plus d’informations, consultez cet article.