Les composants SxS

Si des applications existantes doivent tourner immédiatement, la redirection
DLL sera probablement un bon moyen d’y parvenir.

Vous pouvez faire appel à  des composants SxS pour isoler les composants dans une
application particulière, s’il s’agit de développer une nouvelle application,
ou un jeu de composants partagés pour Windows 2000. L’isolation que permet SxS
permet de profiter à  la fois des DLL et des bibliothèques statiquement liées.
Les composants SxS peuvent exister dans un système Windows 2000 dans lequel pourraient
exister aussi différentes versions du composant. Un composant partagé peut s’exécuter
en même temps qu’une version différente ailleurs sur la même machine.

Lorsque l’on écrit des composants Win32 ou COM compatibles SxS, il faut être conscient
que certaines applications auront besoin de différentes versions de ce composant.
Toutes les informations d’état d’un composant (c’est-à -dire se rapportant aux
structures de données du composant et aux ressources de fichiers ou d’autres ressources
de mémoire) doivent être privées. Pour réaliser cette privatisation, il faut prendre
quelques mesures spécifiques concernant le code lors de l’écriture ou de l’installation.

Windows 2000 offre plusieurs approches pour résoudre le problème des DLL,
l’une d’elles consistant en un changement de programmation

Lorsque l’on écrit un nouveau composant SxS, on lui donne d’abord un nom différent
des précédentes versions du composant non compatibles SxS. On a ainsi la certitude
que la compatibilité amont avec les composants non SxS ne posera pas de problème,
si le nouveau composant est installé sur une machine NT 4.0 ou un autre OS Windows
ne supportant pas les composants SxS.
Il faut aussi séparer les sections de mémoire et les structures de données. Windows
2000 supporte le partage de la mémoire entre plusieurs processus. Les sections
de mémoire sont des objets de gestion de mémoire permettant à  un code partagé
provenant d’un fichier sur disque ou du fichier d’échange, d’être accessible à 
plusieurs applications. Par exemple, une application peut appeler l’API Win32
CreateFileMapping(), qui crée une section de mémoire correspondant à  une certaine
zone de fichier ou de fichier d’échange, dans laquelle le système stocke un composant
partagé. En mode SxS, plusieurs versions d’un composant peuvent s’exécuter en
même temps.
Par conséquent, pour mapper des composants partagés dans la mémoire, évitez d’utiliser
des sections de mémoire pouvant être utilisées par plusieurs processus.
De plus, le composant ne doit pas créer de structures de données partagées en
mémoire ; différentes versions du composant pourraient accéder à  ces structures
de données et risquer de ne pas fonctionner correctement.

Dans le composant SxS, il faut aussi séparer les données des utilisateurs et des
applications. S’il conserve des données spécifiques aux utilisateurs ou aux applications,
celles-ci ne doivent pas être stockées dans un emplacement où elles risqueraient
d’être écrasées par une version différente du composant. Supposons, par exemple,
que vous écriviez un composant COM ou une DLL Win32 permettant à  une application
d’envoyer du courrier électronique par le biais de Microsoft Exchange Server.
Pour ce faire, votre DLL stocke des informations de configuration sur le nom de
la boîte aux lettres par laquelle le système enverra des messages électroniques.
Supposons que le système ait stocké ces informations de configuration dans un
fichier se trouvant dans un emplacement global (par exemple C:\winnt). Supposons,
à  présent, que vous créiez une nouvelle version de votre composant de messagerie,
et que celle-ci modifie le format du fichier stockant les informations de configuration.
La nouvelle version écrasera le fichier de l’ancienne. Résultat, les applications
dépendant de l’ancienne version cesseront de fonctionner.

De même, si votre composant utilise le Registre pour stocker les données des utilisateurs
ou des applications, assurez-vous de stocker ces données dans les clés du Registre
spécifiques à  la version du composant. Par exemple, les informations de configuration
sur le composant de messagerie devraient être stockées dans une clé telle que
HKEY_LOCAL_MACHINE\SOFTWARE\ABCSoftware\MailComponent1.5. Ce type de stockage
dans le Registre sépare les informations de configuration spécifiques à  chaque
version du composant.

Les composants COM posent un problème différent de celui des simples composants
basés sur Win32. Ils s’enregistrent par leur GUID dans HKEY_CLASSES_ROOT. Pour
garantir la privatisation, il est important d’enregistrer correctement les composants
COM SxS. L’enregistrement peut généralement s’effectuer lorsque l’on package l’application
pour l’installation. Le chemin de fichier du composant (par exemple DLL, OCX)
doit être relatif. Les composants COM stockent habituellement leur emplacement
dans le GUID dans la valeur InProcServer32 du Registre et beaucoup de ceux qui
s’enregistrent automatiquement pendant l’installation ou le démarrage enregistrent
leur chemin absolu dans la valeur InProcServer32. Par exemple, si j’installe gadget.dll
dans C:\program files\applicationA et que celle-ci s’enregistre automatiquement,
gadget.dll mettra probablement C:\winnt\system32\gadget.dll dans la valeur InProcServer32.
Cet enregistrement empêche la privatisation, puisque gadget.dll peut très bien
s’installer dans plusieurs répertoires au fur et à  mesure que chaque application
dépendant de lui est installée.
En entrant un chemin relatif, vous êtes certain que, quand l’application dépendante
parcourt le Registre sous la valeur InProcServer32, à  la recherche de gadget.dll,
l’application n’est pas dirigée vers une copie particulière de cette DLL installée
par une application particulière. Lorsqu’une application déployant des composants
COM SxS est installée, il faut s’assurer que le package de l’application utilise
un chemin relatif pour enregistrer les composants COM SxS dans le Registre. Ce
chemin ressemblera à  HKEY_CLASSES_ROOT\CLSID\{01c6b350-12c7-11ce-bd31-00aa004bbb1f}
InProcServer32=gadget.dll.
Dans cet exemple, toute application utilisant gadget.dll trouvera d’abord la version
du composant stockée dans le répertoire de l’application, avant de trouver d’autres
versions dans le système. Microsoft recommande d’inclure dans le compte de références
le GUID de tout objet COM SxS qui s’enregistre. Ce faisant vous serez à  même de
faire le suivi du nombre d’applications utilisant ce GUID ; lorsque toutes les
applications se désinstalleront, la dernière pourra supprimer le GUID du composant
du Registre.

Si vous créez et utilisez des bibliothèques de types pour vos composant, Microsoft
recommande de les compiler dans votre DLL, plutôt que dans un fichier .tlb séparé.
Les bibliothèques de types sont les listes des interfaces supportées par un composant
; les applications et les développeurs les utilisent pour déterminer quelle fonctionnalité
est supportée par un composant. Les composants SxS n’utilisent pas de fichiers
de bibliothèques de types externes, et ne les enregistrent donc pas dans le Registre,
comme c’est le cas des composants courants (dans HKEY_CLASSES_ROOT\TypeLib).

Si un composant accompagne une application particulière, il faut packager
l’installation du composant dans le répertoire de cette application

N’oublions pas qu’il faut aussi privatiser les nouveaux composants SxS installés
dans le système de fichier Windows 2000. Si un composant accompagne une application
particulière, il faut packager l’installation du composant dans le répertoire
de cette application. De même, si plusieurs applications utilisent le même composant,
chacune doit installer la même version de fichier du composant dans son répertoire.
C’est là  le seul moyen de garantir une privatisation robuste des composants.