L'utilisation des composants ActiveX sans inscription préalable dans la base de registre
_{(2ème partie)}

C'est l'élément racine de la structure et il doit appartenir à l'espace de nommage "urn:schemas-microsoft-com:asm.v1". Un unique attribut.

2-1-1-a. manifestVersion (requis)▲

Cet élément est un flag qui inhibe l'héritage du contexte d'activation au profit des threads qui pourraient être créés par le même processus. Le composant non-inscrit devient alors inaccessible pour ces threads. Il est fortement conseillé d'omettre ce flag qui entraine généralement des dysfonctionnements lorsque l'application n'a pas été spécifiquement créée pour gérer le suivi de son propre contexte d'activation au moyen de l'API idoine.

Il doit toujours être placé immédiatement avant l'élément assemblyIdentity concerné par cette inhibition.

Cet élément identifie de façon unique deux notions distinctes :
1° l'application à laquelle s'applique le manifest ;
2° inclus dans un élément dependentAssembly, le fichier assembly manifest qui identifie le composant non-enregistré que l'on souhaite exploiter.

Cette identification est assurée par six attributs.

2-1-3-a. type (requis)▲

2-1-3-b. name (requis)▲

2-1-3-c. language▲

2-1-3-d. processorArchitecture▲

2-1-3-e. version (requis)▲

2-1-3-f. publicKeyToken▲

Cet élément est en principe facultatif mais en pratique obligatoire puisqu'il va contenir un assembly qui permettra de définir le composant que l'on souhaite inclure dans le contexte d'activation. Chaque composant donnera lieu à l'écriture d'un élément dependency séparé.

Cet élément, obligatoirement inclus dans un élément dependency et un seul, contiendra un élément assemblyIdentity tel que décrit ci-dessus.

Cet élément permet de définir les fichiers privés de l'application. Ces fichiers sont identifiés par trois attributs.

2-1-6-a. name▲

2-1-6-b. hashalg▲

2-1-6-c. hash▲

Ce premier élément est identique à celui de l'application manifest ci-dessus.

2-2-1-a. manifestVersion (requis)▲

Cet élément doit être utilisé en coordination avec l'élément noInherit lorsque celui-ci figure dans l'application manifest et précéder immédiatement l'élément assemblyIdentity concerné. Voir l'élément noInherit supra² pour plus d'explications.

Cet élément présente des caractéristiques analogues à celui disponible dans l'application manifest. Il décrit toutefois deux situations différentes :
   - lorsqu'il est le premier sous-élément de l'élément assembly, il décrit l'assembly "propriétaire" de l'assembly manifest. Il est unique et Microsoft le qualifie de DEF-context assembly ;
   - lorsqu'il est un sous-élément d'un élément dependentAssembly, il définit alors un REF-context assembly qui décrit de façon unique l'asssembly utilisé par le DEF-context assembly. À chaque REF-context assembly doit correspondre un DEF-context assembly.

On retrouve également les mêmes attributs (voir ci-dessus) avec les précisions suivantes :

2-2-3-a. name (requis)▲

2-2-3-b. language▲

Il doit contenir au moins un élément dependentAssembly qui doit figurer en premier.

Cet élément doit contenir, en premier élément inclus, un assemblyIdentity. Chacun de ces éléments dependentAssembly doit être inclus dans un élément dependency.

Cet élément dont l'utilité est hypothétique dans un application manifest, est en revanche indispensable pour définir les caractéristiques propres de l'assemblyIdentity propriétaire du manifest autrement dit le DEF-context assembly.

Il possède les trois attributs déjà décrits ci-dessus. Il suffira juste de préciser que l'attribut name correspondra au nom du fichier ActiveX (extension .dll ou .ocx).

Les cinq éléments suivants sont des sous-éléments de l'élément file. Même si la documentation les décrit tous comme facultatifs, en pratique, le sous-élément comClass est au minimum nécessaire pour décrire les caractéristiques de(s) classe(s) exposée(s) par le composant.

2-2-7-a. description▲

2-2-7-b. clsid (requis)▲

2-2-7-c. threadingModel▲

2-2-7-d. tlbid▲

2-2-7-e. progid▲

2-2-7-f. miscStatus▲

2-2-7-g. miscStatusIcon▲

2-2-7-h. miscStatusContent▲

2-2-7-i. miscStatusDocPrint▲

2-2-7-j. miscStatusThumbnail▲

Cet élément précise les caractéristiques de la bibliothèque de type éventuellement présente dans le composant. Il possède cinq attributs :

2-2-8-a. tlbid (requis)▲

2-2-8-b. version (requis)▲

2-2-8-c. helpdir (requis)▲

2-2-8-d. resourceid▲

2-2-8-e. flags▲

Le composant qui constitue le serveur COM possède un mode de gestion cloisonné des threads que l'on définit dans l'attribut threadingModel. Le client COM possède également son propre mode de gestion qui ne sera pas nécessairement compatible avec celui du premier. Aussi, afin de garantir une gestion correcte des appels au serveur, le modèle COM a-t-il prévu une norme particulière en vue de sérialiser l'échange des données entre les différents threads. Ce mécanisme s'appelle le cross-apartment marshalling puisqu'il permet aux données de passer en bon ordre "à travers la cloison".

Lorsqu'il s'agit d'interfaces dérivées d'IDispatch, ce qui est le cas des composants Automation reconnus par VBScript, le couple "entrée/sortie" ou proxy/stub assurant cette sérialisation, est fourni en externe par la bibliothèque ole32.dll d'où le nom de l'attribut. Mais sa création suppose un certain nombre de paramètres qui seront repris dans les attributs ci-dessous. A chaque interface dérivée correspondra un élément comInterfaceExternalProxyStub.

2-2-9-a. iid (requis)▲

2-2-9-b. baseInterface▲

2-2-9-c. numMethods▲

2-2-9-d. name▲

2-2-9-e. tlbid▲

2-2-9-f. proxyStubClsid32▲

Cet élément répond au même besoin que l'élément précédent. La seule différence est qu'il s'applique aux interfaces personnalisées d'un composant qui ne seraient pas dérivées d'IDispatch. Dans ce cas, le proxy/stub doit être créé par la bibliothèque référencée par l'assembly ou par un autre fichier affecté à cet usage et désigné par l'attribut file. Aux attributs similaires à ceux de l'élément précédent s'ajoute un attribut threadingModel qui décrit le modèle de gestion spécifique de l'interface.

2-2-10-a. iid (requis)▲

2-2-10-b. name (requis)▲

2-2-10-c. tlbid▲

2-2-10-d. baseInterface▲

2-2-10-e. numMethods▲

2-2-10-f. proxyStubClsid32▲

2-2-10-g. threadingModel▲

Cet élément ne possède qu'un attribut et permet de contrôler si le nom interne de la classe de la fenêtre peut contenir le numéro de version de l'assembly à l'origine de son enregistrement. Il inclut le nom de la classe de fenêtre.

2-2-11-a. versioned▲

Tout langage capable d'appeler l'API SxS proposée par Microsoft est en mesure de créer, activer, désactiver et détruire des contextes d'activation, et ce à tout moment. Ce sujet qui relève de la programmation win32 n'entre pas dans le champ du présent article et ne sera pas traité ici même s'il est techniquement possible d'écrire des scripts VBS/JS exploitant cette API.

Cet objet est issu d'un composant ActiveX fourni par Microsoft à partir de Windows Server 2003 sous la forme d'un fichier sxsoa.dll. Il permet, notamment pour les langages de script, de créer dynamiquement un contexte d'activation afin d'exploiter directement un composant sans inscription.

Mais alors pourquoi ne pas l'évoquer directement dans la première section au lieu de le décrire seulement après quatre sections d'un article qu'on qualifiera charitablement d'austère ?

Trois raisons à cela :
   - ce composant n'est pas fourni avec Windows XP, même si cet environnement est officiellement supporté ;
   - l'activation implique que la propriété manifest doit contenir le nom du fichier assembly manifest, ce qui signifie que l'on n'est pas dispensé de l'aspect le plus critique de la technique, à savoir l'écriture de ce fichier xml ;
   - ce composant, qui est censé résoudre les problèmes de gestion de ses semblables, doit lui-même être enregistré dans la base de registre. Cette problématique de la poule et de l'œuf ne facilitera pas la vie de l'utilisateur sans droits d'administrateur dans un environnement hostile qui lui refuse l'accès à cette base.

En outre, sa mise en œuvre n'est pas facilitée par une documentation qui semble avoir été rédigée par un stagiaire pas trop motivé qui se serait enfui avant d'avoir terminé le boulot.

La documentation rectifiée devrait plutôt ressembler à ça :

Modèle objet Microsoft.Windows.ActCtx

Propriété :

Manifest (lecture/écriture)
Avant d'appeler la méthode CreateObject de l'objet, il est indispensable de lui fournir au préalable les données du contexte d'activation. Il suffit pour cela d'affecter à la propriété le nom du fichier assembly manifest qui aura été écrit à cet effet. Cette propriété ne peut évidemment pas être en lecture seule comme l'indique la documentation...

Propriétés non documentées :

ManifestText
ManifestURL

Ces deux propriétés ont la même fonction que la propriété officielle mais avec les différences suivantes :
   - ManifestText contient non pas un nom de fichier manifest mais une chaine contenant l'intégralité de l'assembly manifest qui peut ainsi être assemblé en mémoire ;
   - ManifestURL contient le nom du fichier sous la forme d'une adresse de ressource URL.

Méthodes :

CreateObject(objectID[, location])
Contrairement à ce qu'indique la documentation, cette méthode renvoie bien une valeur ou plus précisément une instance de la classe que l'on aura définie dans objectID, c'est-à-dire son progID. Le paramètre facultatif location désigne le nom du serveur distant sur lequel l'objet peut être instancié à l'instar de la méthode native CreateObject de VBScript (omis dans la doc…).

GetObject([moniker],[progID])
Là encore, cette méthode renvoie bien une instance qui, dans ce cas précis, est celle d'une classe existante. Sa syntaxe est identique à celle existant nativement sous VBScript, le moniker étant alors, non pas un nom complet de fichier, mais une valeur de clé de registre (qui est fausse dans la doc, il manque le sous-répertoire SOFTWARE).

Un exemple de script affichant le charset par défaut d'un objet ADO Stream :

Set oSxs = CreateObject("Microsoft.Windows.ActCtx")
oSxs.Manifest = "msado15.sxs.manifest"
Set oS = oSxs.CreateObject("ADODB.Stream")
MsgBox oS.Charset

Ce composant freeware de newObjects, encore disponible sur le net, est un monument à lui tout seul. Son auteur a cessé tout développement depuis septembre 2006 mais l'AXPack1 existe toujours et met à la disposition du développeur un invraisemblable fourre-tout où se côtoient les fonctionnalités les plus improbables. Parmi celles-ci figure la possibilité d'instancier un objet "à la carte" selon une liste impressionnante de paramètres alternatifs. La documentation décrit notamment un mode de création "non-standard" sans s'étendre plus avant sur le sujet.

Cette technique "non-standard" est bien évidemment l'émulation de CoCreateInstance. Elle possède d'ailleurs les inconvénients reconnus de cette technique :
   - nécessite la présence d'une ressource TypeLib dans le fichier ;
   - incompatibilité avec certains composants qui cherchent à accéder spécifiquement à la base de registre quand ils n'ont pas l'idée saugrenue de tenter de s'auto-enregistrer.

Il en existe un troisième qui à notre connaissance n'est jamais évoqué nulle part, c'est la présence requise de l'interface IProvideClassInfo. Nous y reviendrons plus en détail dans la section suivante.

En tout état de cause, la méthode CreateObject de cet objet donne entière satisfaction dans les limites énoncées ci-dessus et il serait dommage de s'en priver d'autant que la documentation a été rédigée avec beaucoup de soin.

Le wrapper peut également se présenter sous la forme d'une bibliothèque DLL classique exposant l'API nécessaire pour instancier les objets d'un composant quelconque. Du point de vue de la portabilité, c'est une solution idéale à partir du moment où le langage du client COM sait appeler ces API. Cet aspect est réglé de façon à peu près satisfaisante pour les langages Active Scripting sous Windows Script Host grâce au composant DynamicWrapperX dont l'intégration sans inscription faisait justement l'objet de la première partie de cet article.

Pour être tout à fait complet, le sujet de cette section devait porter sur une bibliothèque freewareDirectCOM disponible sur le net, écrite par son auteur pour faciliter l'installation de ses produits écrits en VB6.

Malheureusement, les conventions d'appel de cette bibliothèque sont incompatibles avec DynamicWrapperX. Il a donc fallu écrire un wrapper capable de s'accommoder des limites de ce dernier. Cette bibliothèque RegFreeX est disponible ici avec sa documentation.

L'étude en détail de cette émulation a d'ailleurs permis de relever, lorsqu'elle intervient en mode liaison différée, l'existence d'une condition supplémentaire jusque-là inconnue. En effet, si le composant n'expose pas l'interface IProvideClassInfo (c'est le cas de MS ADO), l'appel des méthodes et des propriétés de l'objet échoue. Le composant AXPack1 comme DirectCOM ne proposent pas de solution pour résoudre ce problème.

En revanche, RegFreeX supporte un mode dégradé qu'on pourrait qualifier de "liaison très différée" qui autorise, par le biais d'une méthode CallByNameEx, l'appel de chaque méthode ou propriété de l'objet instancié quand le composant ne fournit pas d'interface IProvideClassInfo.