Introduction :

Avec l’avènement du matériel 64 bits, Microsoft a lancé une version 64 bits de Windows pour tirer parti des capacités de ces plateformes matérielles. La nouvelle version présente l’avantage d’adresser plus de 4 Go de mémoire, d’être plus réactive et d’offrir une meilleure sécurité.

Windows 64 bits est rétrocompatible dans une certaine mesure, ce qui signifie que la plupart des applications 32 bits peuvent fonctionner normalement dessus. Mais les entreprises de logiciels qui souhaitent tirer pleinement parti du 64 bits doivent soit apporter quelques modifications à leurs produits, soit les reconstruire. Cela mène à deux versions du même produit : une pour chaque plateforme Windows.

Les applications gérées peuvent fonctionner dans des environnements 32 bits et 64 bits étant donné qu’elles sont compilées à la dernière minute sur la plateforme cible par le compilateur Just-In-Time (JIT). Cependant, le déploiement sur les deux environnements nécessite deux installateurs différents.

Dans ce blogue, nous montrons comment créer et empaqueter une application gérée d’une manière indépendante de la plateforme. Cela lui permettra de fonctionner sur n’importe quelle plate-forme Windows, et les entreprises finiront par ne maintenir qu’une seule version de leur produit.

Nous commençons par discuter du déploiement des GPO et des environnements de déploiement cibles. Ensuite, nous montrons comment construire la source du produit. Ensuite, nous présentons WiX et discutons de la façon dont nous l’avons utilisé pour empaqueter notre application, et enfin, nous expliquons un problème de déploiement auquel nous avons été confrontés et comment nous l’avons résolu.

Objet de stratégie de groupe (GPO)

GPO est l’abréviation de Group Policy Object, un outil de la famille de systèmes d’exploitation Microsoft Windows NT. Grâce à GPO, un ensemble de règles de contrôle peut être appliqué aux comptes d’utilisateur et aux comptes d’ordinateur Windows. En d’autres termes, GPO précise ce que les utilisateurs peuvent et ne peuvent pas faire sur un système informatique.

Dans le monde Windows, de nombreuses entreprises comptent sur GPO pour déployer leurs applications. Les administrateurs peuvent déployer des progiciels sur n’importe quel nombre de systèmes finaux, et ces déploiements auront lieu selon les paramètres spécifiés par les administrateurs.

Les clients GPO extraient et appliquent les paramètres de politique appropriés à la machine et à l’utilisateur. Certains paramètres nécessitent un redémarrage et/ou une ouverture de session de l’utilisateur, comme l’installation d’un logiciel.

GPO est bon pour gérer un environnement hétérogène de systèmes Windows. Un tel environnement peut contenir différentes versions de Windows.

La figure suivante montre une stratégie créée sous une unité organisationnelle dans Active Directory. La stratégie a un programme d’installation, et la stratégie spécifie que le programme d’installation est basé sur l’utilisateur.

Fig. 1 : Un ensemble d’installation par utilisateur à déployer via GPO.

Compilation d’une application gérée pour fonctionner sur des environnements 32 bits et 64 bits

Le code source du logiciel doit être compilé pour la plateforme Any-CPU. Comme son nom l’indique, cela se traduira par des assemblages indépendants de la plate-forme cible. En d’autres termes, cela permettra de s’assurer que les bibliothèques de liens dynamiques (DLL) et les exécutables résultants fonctionneront sur les plates-formes Windows 32 bits et 64 bits.

La compilation pour Any-CPU permet de s’assurer que les DLL et les exécutables auront accès à toutes les parties du registre du système d’exploitation d’hébergement. C’est très important car les applications 32 bits déployées sur un Windows 64 bits seront limitées uniquement à la partie Wow6432Node du registre; ils ne seront pas en mesure de lire, d’écrire ou même de détecter la partie 64 bits du registre.

Technologie d’installation WiX

De nombreuses options sont disponibles pour écrire un programme d’installation, notamment NSIS, InstallShield, WiX, etc. Chaque technologie a ses avantages et ses inconvénients, mais après avoir examiné chacune d’elles, nous avons choisi d’utiliser WiX.

WiX est un langage XML déclaratif qui produit des programmes d’installation MSI lorsqu’il est compilé, et présente de nombreux avantages :

• Il permet un accès complet aux fonctionnalités du programme d’installation de Windows, y compris les actions personnalisées
• Il est basé sur XML, donc n’importe quel éditeur peut être utilisé pour écrire ses fichiers sources qui sont facilement contrôlés
• C’est gratuit; il n’y a pas de licence coûteuse pour les outils dédiés
• Il a été conçu et maintenu par Microsoft
• Son interface en ligne de commande lui permet d’être intégré dans n’importe quel processus de construction d’application automatisé ou environnement d’intégration continue
• Ses scripts sont écrits de manière à permettre aux développeurs de mettre à jour facilement les parties d’un script Wix spécifiques à un changement qu’ils ont apporté
• Il permet des mises à jour progressives, où seules certaines parties du logiciel sont mises à jour
• Le logiciel déployé est automatiquement enregistré auprès de l’option Ajout/suppression de programmes
• Il fournit une version facile et appropriée de l’installateur

Dans WiX, nous pouvons lister les fichiers que nous voulons déployer et leurs emplacements de déploiement. Nous listons les clés de registre à créer et précisons qu’elles sont par clé utilisateur. Nous énumérons également les conditions préalables requises pour que notre demande soit exécutée. Le programme d’installation est ensuite construit comme un programme d’installation 32 bits.

L’exemple suivant montre à quoi ressemble un fichier source WiX :

<?xml version=’1.0′ encoding=’UTF-8′?>

<Wix

xmlns_netfx=’http ://schemas.microsoft.com/wix/NetFxExtension’>

<Langue du produit=’1033′ …>

<Package InstallerVersion=’100′ compressed=’yes’ manufacturer=’…’ …/>

<Media id=’1′ cabinet=’media1.cab’ embedCab=’yes’ />

<Répertoire>

<ID du répertoire = ‘ProgramFilesFolder’>

<Nom du répertoire = ‘Installation Practice’>

<Composante … />

</Directory>

</Directory>

</Directory>

 

<Composante …>

<Source du fichier=’InstallMe.txt’ />

<RegistryValue Root=’HKCU’ Key=’Software…’ Valeur=’…’ KeyPath=’oui’ / >

</Component>

<Fonctionnalité ConfigurableDirectory=’INSTALLDIR’

Title=’Vircom.dQ.Client.Setup’ Level=’1′>

<Réf. composante/>

…

</Feature>

…

</Product>

</Wix>

Problème d’installation

Une fois que l’administrateur a créé la stratégie de déploiement GPO par utilisateur, un utilisateur final se connecte avec ses informations d’identification sur un système ciblé par la stratégie GPO susmentionnée. Cela lance le programme d’installation de WiX : l’utilisateur reste sur l’écran de connexion pendant l’installation, et une fois l’installation terminée, la connexion se poursuit normalement pour afficher le bureau.

Les installateurs 32 bits qui tentent d’installer sur une machine cible 64 bits seront limités à accéder uniquement aux parties 32 bits du registre. Il s’agit d’un problème pour les applications gérées qui s’attendent à ce que leurs clés de registre se trouvent dans les parties 64 bits du registre, en particulier lorsqu’elles sont hébergées dans une application 64 bits.

Dans notre cas, l’application 32 bits n’a pas pu se lancer dans son hôte 64 bits. Après analyse, nous avons constaté que les fichiers avaient été déployés au bon emplacement sur le disque, mais que les clés de registre de l’utilisateur connecté étaient manquantes sous HKCU 64 bits (HKey_Current_User). Cela a empêché notre application d’être détectée par son hôte.

Pour résoudre le problème, nous avons exécuté regedit en tant qu’administrateur alors que nous étions toujours connectés avec le même compte d’utilisateur et violÃÒ – les clés de registre étaient là sous HKCU. Nous avons réalisé que comme notre application était déployée à l’aide de GPO par utilisateur et que GPO installait l’application à l’aide de l’identité d’un administrateur, les clés de registre HKCU de notre application étaient créées uniquement pour l’administrateur, et non pour le profil de l’utilisateur sur le système cible.

Création de clés de registre personnalisées

Pour résoudre ce problème, nous avons dû nous occuper nous-mêmes de la création des clés de registre. Nous avons écrit un outil simple qui les crée à l’aide des données à stocker et d’un identificateur de sécurité (SID). Le SID est un nom unique attribué par un contrôleur de domaine Windows pendant le processus de connexion pour identifier un utilisateur.

Pour gérer correctement les clés de registre, l’outil les crée sous HKU (HKey_Users) pour le SID spécifié. Les mêmes clés apparaîtront sous HKCU pour l’utilisateur connecté identifié par le SID; c’est parce que HKCU n’est qu’une vue des clés de registre pour le profil d’utilisateur connecté actuel. Ce profil est stocké sous HKU avec tous les autres profils d’utilisateurs qui se sont connectés précédemment au système, chacun avec un SID unique. De cette façon, les clés de registre de l’application seraient ensuite trouvées sous HKCU, comme prévu.

Cet outil personnalisé a été intégré dans le programme d’installation de WiX. Lorsqu’il est déployé via GPO, le programme d’installation de WiX connaît le SID de l’utilisateur qui se connecte. Selon la plate-forme cible, Wix lancera l’outil, en utilisant une action personnalisée sous forme de processus 64 bits ou 32 bits. Wix passe le SID de l’utilisateur actuellement connecté. Cela permet à l’outil personnalisé de créer les clés de registre pour le profil d’utilisateur approprié et à l’emplacement approprié du registre.

En conclusion

Nous avons montré comment créer et empaqueter une application gérée pour qu’elle s’exécute sur les plateformes Windows 32 bits et 64 bits. Il en résulte une version de l’application à maintenir. L’avantage est une réduction des coûts d’entretien et de développement pour les producteurs, ainsi qu’un déploiement et une gestion faciles pour les clients.

Références

1. WiX : Guide du développeur sur Windows Installer XML, Nick Ramirez, PACKT 2010
2. Msdn.microsoft.com
3. Wikipedia.org