Discussion :

[sokai]

Une classe est enregistrée dans la registery.

Comment savoir de quelle DLL vient cette classe ?

[Médinoc]

Tu parles de classe COM? C'est bien simple:
La clé HKCR\CLSID\{CLSID de la classe}\InprocServer32 contient le chemin de la DLL.
S'il n'y a pas de clé InprocServer32, c'est qu'il s'agit d'un composant out-of-process au lieu d'un composant inproc.

Aussi, si la DLL est MSCOREE.DLL, c'est qu'il s'agit en réalité d'une classe .Net, et le nom de la DLL qui la contient est dans les sous-clés de InprocServer32.

[sokai]

Alors oui c'est bien une classe COM et la DLL n'est pas MSCOREE.DLL.

La classe dont je cherche la DLL s'appelle "pdfDistiller".

Par contre, je n'ai pas trouvé de clé InprocServer32... et donc aucun demain de DLL...

[Médinoc]

Il y a donc sans doute un LocalServer32 à la place, et peut-être un InprocHandler32 s'il s'agit d'une classe OLE.

[sokai]

Bon j'ai reparcouru toute la registery mais je n'ai pas trouvé de
LocalServer32 ou InprocHandler32 en recherchant le nom de ma classe.

Par contre j'ai réussi à trouver la DLL (en peu par chance) grâce à visual studio (MVS) et l'ajout de préférences. Par contre quelques détails me taquinent.

1) Je n'ai donc toujours pas de moyen de trouver la DLL dont appartient la classe dans ma registery sans MVS

2) Dans MVS lors de l'ajout de préférence il faut bien spécifier une DLL ?

3) Pourquoi lorsque je veux ajouter la DLL d'acrobat distiller le chemin de acrodist.exe est spécifié et pas le chemin de la DLL ? (La DLL serait dans le .exe ?)

4) Une fois la DLL ajoutée aux préférences, il est possible de parcourir les méthodes et propriétés des classes grâce à l'explorateur d'objet. Maintenant supposons que je n'ai pas visual studio comment faire pour visualiser les méthodes et propriétés des classes de ma DLL ? Y a-t-il un moyen de faire cela avec les outils de base de window XP ?

PS: Pour info la DLL de la classe "PdfDistiller" est "Interop.ACRODISTXLib.dll"

[Médinoc]

Par nom de la classe, tu veux dire son ProgID?

[Médinoc]

Interop.quelque chose, c'est une classe générée par Visual.
Typiquement, générée pour qu'une assembly .Net puisse appeler des classes COM.

Ce que tu as rajouté au projet, ce n'est pas la classe elle-même, mais sa Type Library (bibliothèque de types), référencée dans HKCR\TypeLib.

[sokai]

Interop.quelque chose, c'est une classe générée par Visual.
Typiquement, générée pour qu'une assembly .Net puisse appeler des classes COM.

C'est vraiment juste une classe ?

Ce que tu as rajouté au projet, ce n'est pas la classe elle-même, mais sa Type Library (bibliothèque de types), référencée dans HKCR\TypeLib.

Merci pour les infos par contre ça ne répond pas vraiment à mes questions 1, 4

[Médinoc]

N'oublie pas qu'il y a différentes choses qui référencent une classe COM:

• ProgId (avec ou sans version)
• CLSID
• AppId (optionnel, surtout utilisé pour DCOM)
• LIBID (pour les bibliothèques de types, clé TypeLib du registre)

Le registre peut aussi contenir les IID de certaines interfaces, pour indiquer le proxy/stub à utiliser lors du marshalling, et/ou le LibId d'une bibliothèque de types qui la décrit...

Quand on ajoute une référence COM à un projet Visual Studio, c'est via la bibliothèque de type, pas via le ProgId.

[sokai]

J'ai essayé avec une autre classe plus commune "word.application",
j'ai bien trouvé le InprocServer32 avec le nom de la DLL
par contre ca ne marche pas avec "PdfDistiller.PdfDistiller"


Partons d'un exemple simple si non il y a trop de voies ^^

J'ai le ProgId d'une classe étant enregistrée dans la registery.

1) Est-il possible de retrouver la DLL d'où vient cette classe si il n'y a pas de InprocServer32, LocalServer32 ou InprocHandler32 ?

2) [IMPORANT] Est-il possible d'accéder aux méthodes et propriétés de cette classe ?
(si possible avec des outils windows)

C'est tout ce que je voudrais savoir ^^

[Médinoc]

1. S'il n'y a aucun des trois, alors ça ne marchera pas à l'exécution: CoCreateInstance() foirera avec REGDB_E_CLASSNOTREG.
2. Tu veux dire voir leur déclaration? Vu qu'il y a une bibliothèque de types, sans doute que oui. Pas avec des outils "Windows", mais avec un outil "Visual": Le OLE/COM Object Viewer (OLEVIEW.EXE) possède une option pour voir le contenu d'une bibliothèque de types.

Plus d'infos: http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx

[sokai]

Ok merci beaucoup Médinoc !

[Médinoc]

PS: Pourrais-tu poster le contenu complet de la clé de registre en question? (celle dans CLSID)

[sokai]

{1CD675B2-ECD1-11D1-B976-00600802DB86}

[Médinoc]

PS: Pourrais-tu poster le contenu complet de la clé de registre en question? (celle dans CLSID)

[sokai]

{1CD675B2-ECD1-11D1-B976-00600802DB86}
-LocalServer32 > C:\PROGRA~1\Adobe\ACROBA~1.0\Distillr\acrodist.exe
-ProgID > PdfDistiller.PdfDistiller.1
-Programmable > vide
-VersionIndependentProgID > PdfDistiller.PdfDistiller

Voila

[Médinoc]

C'est donc bien un composant out-of-process: Il n'est pas implémenté par une DLL COM, mais par un Exe qui appelle CoRegisterClassObject() ou RegisterActiveObject() une fois lancé.

[sokai]

et donc dans ce cas impossible de savoir de quelle DLL il vient ?

[Médinoc]

Ben non, puisqu'il ne vient PAS d'une DLL.

[sokai]

C'est donc bien un composant out-of-process: Il n'est pas implémenté par une DLL COM, mais par un Exe qui appelle CoRegisterClassObject() ou RegisterActiveObject() une fois lancé.

Donc il y a si j'ai bien compris :

Des entrées dans la registery (afin d'appeler des classe ou fonction) qui pointe ou sur:
Un .exe comme ca dernier cas
Une interface pour les DLL COM

Par contre il y a encore quelque chose d'étrange... pour "word.application"
il y a un InprocHandler32 > ole32.dll
InprocServer32
Assembly >Microsoft.Office.Interop.Word, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C
Class > Microsoft.Office.Interop.Word.ApplicationClass
RuntimeVersion > v1.1.4322

Donc voila cette classe word.application n'est pas dans ole32...
Il n'y a pas d'exe n'y d'interface pointant sur une DLL donc ou se trouve cette classe ? -_-;