Préparer l’empaquetage d’une application de bureau
Cet article rappelle les points à connaître avant de créer un package d’application de bureau. Vous n’aurez probablement pas grand-chose à faire pour préparer votre application au processus de création de package. Toutefois, si l’un des éléments ci-dessous s’applique à votre application, vous devez y remédier au préalable.
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 s’exécute toujours avec des privilèges élevés de sécurité. Votre application a besoin de travailler lors de l’exécution en tant qu’utilisateur interactif. Les utilisateurs qui installent votre application ne sont peut-être pas des administrateurs système. Par conséquent, exiger que votre application s’exécute avec élévation de privilèges signifie qu’elle ne s’exécutera pas correctement pour les utilisateurs standard. Si vous envisagez de publier votre application dans le Microsoft Store, sachez que les applications qui exigent une élévation de privilèges pour une partie de leurs fonctionnalités n’y sont pas acceptées.
Votre application nécessite un pilote Windows. MSIX ne prend pas en charge les pilotes Windows.
Votre application nécessite un service Windows utilisateur. MSIX ne prend pas en charge les services Windows par utilisateur. MSIX prend en charge les services session-0 (par ordinateur) exécutés sous l’un des comptes système définis (LocalSystem, LocalService ou NetworkService). Au lieu d’un service Windows utilisateur, utilisez une tâche en arrière-plan.
Les modules de votre application sont chargés in-process sur les processus ne figurant pas dans votre package d’application Windows. Cela n’est pas autorisé, ce qui signifie que les extensions in-process, comme les extensions shell, ne sont pas prises en charge. Mais si vous avez deux applications dans le même package, vous pouvez effectuer une communication entre eux.
Assurez-vous que toutes les extensions installées par l’application vont s’installer à l’emplacement auquel l’application est installée. Windows permet aux utilisateurs et aux responsables informatiques de changer l’emplacement d’installation par défaut des packages. Consultez « Paramètres->Système->Stockage->Autres paramètres de stockage->Modifier l’emplacement d’enregistrement du nouveau contenu->Les nouvelles applications seront enregistrées à l’emplacement suivant ». Si vous installez une extension avec votre application, vérifiez que cette extension n’a pas d’autres restrictions de dossier d’installation. Par exemple, certaines extensions peuvent désactiver l’installation de leur extension sur des lecteurs non-système. Une erreur 0x80073D01 (ERROR_DEPLOYMENT_BLOCKED_BY_POLICY) est alors générée si l’emplacement par défaut a été modifié.
Votre application utilise un ID de modèle utilisateur de l’application (AUMID) personnalisé. Si votre processus appelle SetCurrentProcessExplicitAppUserModelID pour définir son propre AUMID, il peut uniquement utiliser l’AUMID généré pour lui par l’environnement de modèle de l’application/du package d’application Windows. Vous ne pouvez pas définir d’AUMID personnalisés.
Votre application modifie la ruche du Registre HKEY_LOCAL_MACHINE (HKLM). Toute tentative par votre application de créer une clé HKLM ou d’en ouvrir une pour modification donne lieu à une erreur d’accès refusé. N’oubliez pas que votre application dispose de sa propre vue privée virtualisée du Registre. La notion de ruche du Registre de l’utilisateur ou de l’ordinateur (la définition de HKLM) ne s’applique pas. Vous devrez trouver un autre moyen d’obtenir ce que vous utilisiez HKLM pour, comme écrire à HKEY_CURRENT_USER (HKCU) à la place.
Votre application utilise une sous-clé de Registre ddeexec comme moyen de lancement d’une autre application. Utilisez plutôt l’un des gestionnaires de verbe DelegateExecute comme configuré par les différentes extensions Activateable* dans le manifeste de package d’application.
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.
Utilisez un autre moyen de partage de données interprocesseur. Pour en savoir plus, voir Stocker et récupérer des paramètres et autres données d’application.
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. Vous devez donc trouver un autre emplacement, comme le magasin de données d’application local.
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.
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.
L’installation de votre application nécessite l’intervention de l’utilisateur. Le programme d’installation de votre application doit être en mesure de s’exécuter en silence, et il doit installer tous les éléments requis qui ne sont pas disponibles par défaut sur une nouvelle image de système d’exploitation.
Votre application expose des objets COM. Les processus et extensions peuvent, au sein du package, enregistrer et utiliser les serveurs COM et OLE, pour les modes in-process et out-of-process (OOP). Creators Update ajoute la prise en charge des COM empaquetés qui offre la possibilité d’inscrire les serveurs OOP COM et OLE qui sont désormais visibles en dehors du package. Consultez Prise en charge des documents COM et OLE pour le Pont du bureau.
La prise en charge des COM empaquetés fonctionne avec les API COM existantes, mais elle ne fonctionne pas avec les extensions d’application qui s’appuient sur la lecture directe du registre, car l’emplacement des COM empaquetés est de type privé.
Votre application expose des assemblys GAC pour que ces derniers soient utilisés par d’autres processus. Votre application ne peut pas exposer des assemblys GAC pour une utilisation par des processus issus de fichiers exécutables externes à votre package d’application Windows. Les processus issus du package peuvent enregistrer et utiliser des assemblys GAC normalement, mais ceux-ci ne seront pas visibles en externe. Cela signifie que les scénarios d’interopérabilité tels que OLE ne fonctionnent pas s’ils sont appelés par des processus externes.
Votre application lie des bibliothèques runtime C d’une manière non prise en charge. La bibliothèque C/C++ runtime de Microsoft fournit des routines de programmation pour le système d’exploitation Microsoft Windows. Ces routines automatisent de nombreuses tâches de programmation courantes qui ne sont pas fournies par les langages C et C++. Si votre application utilise la bibliothèque runtime C/C++, vous devez vous assurer que la liaison de celle-ci est prise en charge.
Visual Studio 2017 prend en charge à la fois la liaison statique et dynamique (pour que votre code puisse utiliser des fichiers DLL courants) et la liaison statique (pour lier la bibliothèque directement dans votre code) à la version actuelle du CRT. Si possible, nous vous recommandons d’utiliser la liaison dynamique avec Visual Studio 2017 pour votre application.
La prise en charge dans les versions précédentes de Visual Studio varie. Pour plus de détails, consultez le tableau suivant :
Version Visual Studio Liaison dynamique Liaison statique 2005 (VC 8) Non pris en charge Prise en charge 2008 (VC 9) Non pris en charge Prise en charge 2010 (VC 10) Prise en charge Prise en charge 2012 (VC 11) Prise en charge Non pris en charge 2013 (VC 12) Prise en charge Non pris en charge 2015 et 2017 (VC 14) Prise en charge Prise en charge Remarque : dans tous les cas, vous devez créer une liaison vers la toute dernière version de CRT disponible publiquement.
Votre application installe et charge des assemblys à partir du dossier Windows côte-à-côte. Par exemple, votre application utilise des bibliothèques runtime C VC8 ou VC9 et les lie dynamiquement à partir du dossier Windows côte-à-côte, ce qui signifie que votre code utilise les fichiers DLL courants à partir d’un dossier partagé. 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.
Votre application utilise une dépendance dans le dossier System32/SysWOW64. Pour que ces DLL fonctionnent, vous devez les inclure dans la partie du système de fichiers virtuel de votre package d’application Windows. Ainsi, l’application se comporte comme si les fichiers DLL avaient été installés dans le dossier System32/SysWOW64. À la racine du package, créez un dossier appelé VFS. Dans ce dossier, créez un dossier SystemX64 et SystemX86. Ensuite, placez la version 32 bits de votre DLL dans le dossier SystemX86 et placez la version 64 bits dans le dossier SystemX64.
Votre application utilise un package d’infrastructure VCLibs. Si vous convertissez une application Win32 C++, vous devez gérer le déploiement du runtime Visual C++. Visual Studio 2019 et le SDK Windows incluent les packages d’infrastructure les plus récents pour les versions 11.0, 12.0 et 14.0 du runtime Visual C++ dans les dossiers suivants :
Packages d’infrastructure VC 14.0 : C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop\14.0
Packages d’infrastructure VC 12.0 : C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop.120\14.0
Packages d’infrastructure VC 11.0 : C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.VCLibs.Desktop.110\14.0
Pour utiliser l’un de ces packages, vous devez le référencer en tant que dépendance dans le manifeste du package. Lorsque les clients installent la version commercialisée de votre application à partir du Microsoft Store, le package est installé à partir du Store en même temps que votre application. Si vous chargez indépendamment votre application, les dépendances ne s’installent pas. Pour installer les dépendances manuellement, vous devez installer le package d’infrastructure approprié à l’aide du package .appx approprié pour x86, x64 ou ARM situé dans les dossiers d’installation listés ci-dessus.
Pour référencer un package d’infrastructure du runtime Visual C++ dans votre application :
Accédez au dossier d’installation du package d’infrastructure listé ci-dessus pour la version du runtime Visual C++ utilisée par votre application.
Ouvrez le fichier SDKManifest.xml dans ce dossier, recherchez l’attribut
FrameworkIdentity-DebugouFrameworkIdentity-Retail(selon que vous utilisez la version de débogage ou la version commerciale du runtime), puis copiez les valeursNameetMinVersionde cet attribut. Par exemple, voici l’attributFrameworkIdentity-Retaildu package d’infrastructure VC 14.0 actuel.FrameworkIdentity-Retail = "Name = Microsoft.VCLibs.140.00.UWPDesktop, MinVersion = 14.0.27323.0, Publisher = 'CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US'"Dans le manifeste du package de votre application, ajoutez l’élément
<PackageDependency>suivant sous le nœud<Dependencies>. Veillez à remplacer les valeursNameetMinVersionpar les valeurs que vous avez copiées à l’étape précédente. L’exemple suivant spécifie une dépendance pour la version actuelle du package d’infrastructure VC 14.0.<PackageDependency Name="Microsoft.VCLibs.140.00.UWPDesktop" MinVersion="14.0.27323.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
Votre application contient la liste des raccourcis personnalisée. Il existe plusieurs problèmes et mises en garde à connaître concernant l’utilisation des listes de raccourcis.
L’architecture de votre application ne correspond pas au système d’exploitation. Pour l’instant, les listes de raccourcis ne fonctionnent pas correctement si l’architecture de l’application ne correspond à celle du système d’exploitation (par exemple, exécution d’une application x86 sur Windows x64 ). À ce stade, la recompilation de votre application vers l’architecture correspondante constitue l’unique solution de contournement existante.
Votre application crée des entrées de liste de raccourcis et appelle ICustomDestinationList::SetAppID ou SetCurrentProcessExplicitAppUserModelID. Ne définissez pas par programmation votre AppID dans le code. Cela entraîne l’affichage des entrées de votre liste de raccourcis. Si vous devez définir un ID personnalisé pour votre application, faites-le en utilisant le fichier manifeste. Pour obtenir des instructions, reportez-vous à Créer un package d’une application de bureau manuellement. L’AppID de votre application est spécifié dans la section YOUR_PRAID_HERE.
Votre application ajoute un lien shell de liste de raccourcis qui fait référence à un exécutable dans votre package. Vous ne pouvez pas lancer des exécutables dans votre package directement à partir d’une liste de raccourcis (sauf pour le chemin d’accès absolu du propre fichier .exe d’une application). Au lieu de cela, inscrivez un alias d’exécution d’application (qui permet à votre application de bureau empaquetée d’être démarrée à l’aide d’un mot clé comme si elle était définie dans la variable PATH) et définissez le chemin cible du lien sur l’alias. Pour plus d’informations sur l’utilisation de l’extension appExecutionAlias, consultez Intégrer votre application de bureau à Windows 10. Notez que si vous avez besoin de ressources du lien dans la liste de raccourcis pour correspondre au fichier .exe d’origine, vous devez définir des ressources telles que l’icône à l’aide de SetIconLocation et le nom complet avec PKEY_Title comme vous le feriez pour d’autres entrées personnalisées.
Votre application ajoute des entrées de liste de raccourcis qui font référence aux ressources dans le package de l’application par des chemins absolus. Le chemin d’installation d’une application peut changer lors d’une mise à jour de ses packages qui modifie l’emplacement des ressources (icônes, documents, exécutables, etc.). Si des entrées de liste de raccourcis font référence à ces ressources par des chemins absolus, l’application doit actualiser régulièrement sa liste de raccourcis (par exemple, au démarrage) pour garantir la résolution correcte des chemins. Vous pouvez également utiliser les API Windows.UI.StartScreen.JumpList UWP à la place, ce qui vous permet de référencer des ressources de chaîne et d’image à l’aide du modèle d’URI ms-resource relatif au package (qui est également un langage, un PPP et un contraste élevé).
Votre application démarre un utilitaire pour effectuer des tâches. Évitez de démarrer des utilitaires de commande tels que PowerShell et Cmd.exe. En fait, si les utilisateurs installent votre application sur un système fonctionnant sur Windows 10 S, elle ne sera pas du tout en mesure de les démarrer. Cela peut bloquer la soumission de votre application au Microsoft Store, car toutes les applications soumises au Microsoft Store doivent être compatibles avec Windows 10 S.
Le démarrage d’un utilitaire constitue souvent un moyen pratique de chercher des informations dans le système d’exploitation, le registre ou les fonctionnalités d’accès au système. Toutefois, vous pouvez tout aussi bien utiliser les API UWP pour accomplir ces types de tâches. Ces API sont plus performantes, car elles n’ont besoin d’aucun fichier exécutable séparé pour s’exécuter, mais, plus important encore, elles empêchent l’application de sortir du package. La conception de l’application reste cohérente avec l’isolement, la confiance et la sécurité qui accompagnent une application dont vous avez créé le package. Votre application se comportera comme prévu sur les systèmes exécutant Windows 10 S.
Votre application héberge des compléments, des plug-ins ou des extensions. Dans de nombreux cas, les extensions de type COM continueront probablement à fonctionner tant qu’elles n’auront pas été packagées et elles s’installeront en toute confiance. La raison est que ces programmes d’installation peuvent utiliser leurs capacités de confiance totale pour modifier le registre et placer les fichiers d’extension partout où votre application hôte s’attend à les trouver.
Toutefois, si ces extensions sont packagées, puis installées comme un package d’application Windows, elles ne fonctionneront pas car les packages (l’application hôte et l’extension) seront isolés les uns des autres. Pour en savoir davantage sur la méthode utilisée par le Pont du bureau pour isoler les applications du système, consultez Fonctionnement détaillé du Pont du bureau.
Toutes les applications et les extensions installées par des utilisateurs sur un système exécutant Windows 10 S doivent être installées en tant que packages d’application Windows. Par conséquent, si vous envisagez de créer des packages de vos extensions ou si vous prévoyez d’encourager vos collaborateurs à les packager, déterminez la méthode à employer pour faciliter la communication entre le package d’application hôte et tous les packages d’extension. L’utilisation d’un service d’application peut être un bon moyen pour accomplir cette opération.
Votre application génère du code. Votre application peut générer du code qu’elle consomme en mémoire, toutefois, vous devez éviter d’écrire le code généré sur le disque car le processus de certification d’application Windows ne peut pas valider ce code avant la soumission de l’application. De plus, les applications qui écrivent du code sur le disque ne fonctionnent pas correctement sur les systèmes exécutant Windows 10 S. Cela peut bloquer la soumission de votre application au Microsoft Store, car toutes les applications soumises au Microsoft Store doivent être compatibles avec Windows 10 S.
Important
Une fois que vous avez créé votre package d’application Windows, testez votre application pour vous assurer qu’elle fonctionne correctement sur les systèmes qui exécutent Windows 10 S. Toutes les applications soumises au Microsoft Store doivent être compatibles avec les applications Windows 10 S. Celles qui ne le sont pas ne seront pas acceptées dans le Store. Consultez Tester votre application Windows pour Windows 10 S.