Isolator - simplification du déploiement et élimination de "l'enfer des dll"
Description
Bonjour,
Cette application a pour but de supprimer tout besoin d'enregistrement des ActiveX en base de registres.
Reprenons en détail.
Vous savez surement qu'il existe en gros deux sortes de Dll.
Les Dll dites classiques (d'API) et les Dll ActiveX.
Ces dernières permettent d'exporter des classes. Vous avez surement déjà utilisé des objets tels que :
- Scripting.FileSystemObject
- Excel.Application
- VbScript.RegExp
- ...
Toutes ces classes sont issues de la technologie COM ActiveX.
Une classe est caractérisée par le nom de sa librairie (ex: Scripting) et le nom de la classe (FileSystemObject).
Lorsque vous faites par exemple, en VbScript :
Set oFSO = CreateObject("Scripting.FileSystemObject")
que se passe-t'il ?
Le moteur de script va chercher dans la base de registres.
observons:
HKEY_CLASSES_ROOT\Scripting.FileSystemObject
nous y trouvons un identifiant globallement unique, le CLSID (Class ID) qui est donc :
HKEY_CLASSES_ROOT\Scripting.FileSystemObject\CLSID = {0D43FE01-F093-11CF-8940-00A0C9054228}
Ok, "Scripting.FileSystemObject" permet de trouver le CLSID...
Qu'en faire ?
Et bien toujours en base de registres :
HKEY_CLASSES_ROOT\CLSID\{0D43FE01-F093-11CF-8940-00A0C9054228}
Cette clé possède la clé InprocServer32 qui permet enfin de faire le lien avec le fichier .dll :
HKEY_CLASSES_ROOT\CLSID\{0D43FE01-F093-11CF-8940-00A0C9054228}\InprocServer32 = C:\WINDOWS\system32\scrrun.dll
En fait, lorsque vous enregistrez vos Dll (Via RegSvr32 le plus souvent) ; ce sont toutes ces informations qui sont inscrites en base de registres. Tout ce qui permettra de passer de "Scripting.FileSystemObject" à un nom de dll et un identifiant de la classe à instancier.
Bon, ça c'est pour le Late-Binding (liaison tardive) ; c'est à dire en utilisant le nom de la classe comme point de départ.
Il existe également le Early-Binding qui est en fait simplement le contraire. C'est ce que vous observez dans les langages compilés tels que VB6 (par exemple). En effet, dans les references de votre projet, vous pouvez lier ce dernier à un certain nombre de Dll ActiveX. Dans le projet, par la suite et dans l'executable que vous générez, il est directement inscrit le CLSID, ce qui réduit le nombre de recherches en base de registres. Sans compter que là, les objets sont typés, pas déclarés en tant que 'As Object'... Du coup, l'execution est un brin plus lente, VB n'ayant pas a s'assurer que telle ou telle fonction existe...
Revenons à nos moutons...
Microsoft, avec Windows 2000 à introduit les fichiers .manifest.
Il s'agit d'un simple fichier XML, permettant de spécifier certaines infos qui prévallent sur ce qui pourrait être trouvé en base de registres.
Pour un executable nommé Project1.exe, le manifest correspondant se nommera donc Project1.exe.manifest
Vous avez surement entendu parler de ces fichiers pour appliquer le thème de Windows à vos applications.
C'est exactement le même phénomène. On précise en fait que l'on souhaite remplacer le lien vers la Dll des controles communs par la version 6.0 de cette Dll, gérant le thème Windows.
L'application que je vous présente ici permet de générer des fichiers manifest pour rendre inutile l'enregistrement de vos ActiveX.
Concrêtement, un manifest pour l'executable va identifier les Dll ActiveX requises. Un second fichier manifest (en fait, un par ActiveX) sera créé, pour lister les classes exportées.
Ainsi, lorsque Windows va charger l'application, il va regarder si un fichier manifest est présent. Il va le charger s'il le faut, et placer toutes ces règles en mémoire.
Ainsi, lorsqu'il lui sera demandé la classe "Test.Class1" (ou via son CLSID), Windows saura faire le lien avec la dll, grâce au manifest. Pas besoin d'aller fureter en base de registres, donc.
à noter que le manifest peut etre intégré directement aux .exe (dans ses ressources).
Cela vous permet donc de simplement 'poser' la dll dans le repertoire de l'application, sans passer par la case RegSvr32. Rappelons que cette opération requiert bien souvent les droits administrateur... Cela devient donc bien intéressant...
Voir exemple dans le dossier Sample.
En renommant correctement les fichiers (.ex_ => .exe .dl_ => .dll)
Et en les chargeant dans l'application "Isolator" vous pourrez générer les fichiers d'isolement ".manifest" qui vous permettrons de lancer Project1.exe (lequel requiert la dll) sans avoir a enregistrer l'ActiveX...
Cette application a pour but de supprimer tout besoin d'enregistrement des ActiveX en base de registres.
Reprenons en détail.
Vous savez surement qu'il existe en gros deux sortes de Dll.
Les Dll dites classiques (d'API) et les Dll ActiveX.
Ces dernières permettent d'exporter des classes. Vous avez surement déjà utilisé des objets tels que :
- Scripting.FileSystemObject
- Excel.Application
- VbScript.RegExp
- ...
Toutes ces classes sont issues de la technologie COM ActiveX.
Une classe est caractérisée par le nom de sa librairie (ex: Scripting) et le nom de la classe (FileSystemObject).
Lorsque vous faites par exemple, en VbScript :
Set oFSO = CreateObject("Scripting.FileSystemObject")
que se passe-t'il ?
Le moteur de script va chercher dans la base de registres.
observons:
HKEY_CLASSES_ROOT\Scripting.FileSystemObject
nous y trouvons un identifiant globallement unique, le CLSID (Class ID) qui est donc :
HKEY_CLASSES_ROOT\Scripting.FileSystemObject\CLSID = {0D43FE01-F093-11CF-8940-00A0C9054228}
Ok, "Scripting.FileSystemObject" permet de trouver le CLSID...
Qu'en faire ?
Et bien toujours en base de registres :
HKEY_CLASSES_ROOT\CLSID\{0D43FE01-F093-11CF-8940-00A0C9054228}
Cette clé possède la clé InprocServer32 qui permet enfin de faire le lien avec le fichier .dll :
HKEY_CLASSES_ROOT\CLSID\{0D43FE01-F093-11CF-8940-00A0C9054228}\InprocServer32 = C:\WINDOWS\system32\scrrun.dll
En fait, lorsque vous enregistrez vos Dll (Via RegSvr32 le plus souvent) ; ce sont toutes ces informations qui sont inscrites en base de registres. Tout ce qui permettra de passer de "Scripting.FileSystemObject" à un nom de dll et un identifiant de la classe à instancier.
Bon, ça c'est pour le Late-Binding (liaison tardive) ; c'est à dire en utilisant le nom de la classe comme point de départ.
Il existe également le Early-Binding qui est en fait simplement le contraire. C'est ce que vous observez dans les langages compilés tels que VB6 (par exemple). En effet, dans les references de votre projet, vous pouvez lier ce dernier à un certain nombre de Dll ActiveX. Dans le projet, par la suite et dans l'executable que vous générez, il est directement inscrit le CLSID, ce qui réduit le nombre de recherches en base de registres. Sans compter que là, les objets sont typés, pas déclarés en tant que 'As Object'... Du coup, l'execution est un brin plus lente, VB n'ayant pas a s'assurer que telle ou telle fonction existe...
Revenons à nos moutons...
Microsoft, avec Windows 2000 à introduit les fichiers .manifest.
Il s'agit d'un simple fichier XML, permettant de spécifier certaines infos qui prévallent sur ce qui pourrait être trouvé en base de registres.
Pour un executable nommé Project1.exe, le manifest correspondant se nommera donc Project1.exe.manifest
Vous avez surement entendu parler de ces fichiers pour appliquer le thème de Windows à vos applications.
C'est exactement le même phénomène. On précise en fait que l'on souhaite remplacer le lien vers la Dll des controles communs par la version 6.0 de cette Dll, gérant le thème Windows.
L'application que je vous présente ici permet de générer des fichiers manifest pour rendre inutile l'enregistrement de vos ActiveX.
Concrêtement, un manifest pour l'executable va identifier les Dll ActiveX requises. Un second fichier manifest (en fait, un par ActiveX) sera créé, pour lister les classes exportées.
Ainsi, lorsque Windows va charger l'application, il va regarder si un fichier manifest est présent. Il va le charger s'il le faut, et placer toutes ces règles en mémoire.
Ainsi, lorsqu'il lui sera demandé la classe "Test.Class1" (ou via son CLSID), Windows saura faire le lien avec la dll, grâce au manifest. Pas besoin d'aller fureter en base de registres, donc.
à noter que le manifest peut etre intégré directement aux .exe (dans ses ressources).
Cela vous permet donc de simplement 'poser' la dll dans le repertoire de l'application, sans passer par la case RegSvr32. Rappelons que cette opération requiert bien souvent les droits administrateur... Cela devient donc bien intéressant...
Conclusion :
Voir exemple dans le dossier Sample.
En renommant correctement les fichiers (.ex_ => .exe .dl_ => .dll)
Et en les chargeant dans l'application "Isolator" vous pourrez générer les fichiers d'isolement ".manifest" qui vous permettrons de lancer Project1.exe (lequel requiert la dll) sans avoir a enregistrer l'ActiveX...
Codes Sources
A voir également
- Isolator - simplification du déploiement et élimination de "l'enfer des dll"
- Simplification de fraction - Forum C / C++ / C++.NET
- Décompiler dll - Conseils pratiques -C# / .NET
- Déploiement d une application web - Forum C# / .NET
- Dll decompiler online ✓ - Forum C# / .NET
- Décompiler une dll - Forum Visual Basic
Vous n'êtes pas encore membre ?
inscrivez-vous, c'est gratuit et ça prend moins d'une minute !
Les membres obtiennent plus de réponses que les utilisateurs anonymes.
Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.
Le fait d'être membre vous permet d'avoir des options supplémentaires.