COM à .NET interopérabilité

Question

Si vous souhaitez utiliser un type COM dans votre C# Code, le processus est simple, non? Vous avez juste besoin d'utiliser l'importateur de bibliothèque de type et c'est très bien, mais si vous n'avez pas et vous ne pouvez pas jeter un oeil à la fichier IDL? Vous venez d'avoir le serveur DLL COM.

À titre d'exemple, essayez d'utiliser l'interface IActiveDesktop.

Quelle est l'approche utilisée pour résoudre ce genre de problème?

Answer 1

Il existe deux types d'interfaces COM. Celui que vous connaissez est celui qui se limite à un sous-ensemble de la spécification COM appelée "OLE Automation". Également connu sous le nom d'ActiveX avant que ce terme ne soit associé à des problèmes de sécurité.

Les interfaces compatibles avec l'automatisation sont faciles à utiliser dans pratiquement toutes les langues. Ils héritent généralement de IDispatch, ce qui leur permet d'être utilisés à partir de langages de script. Et se limiter à utiliser uniquement des types compatibles avec l'automatisation pour leurs arguments de méthode. Les choses simples, comparables aux types de valeurs .NET, BSTR pour les chaînes, SAFEARRAY pour les tableaux, VARIANT pour les arguments non typés, assez similaire à System.Object .NET.

Une autre caractéristique qu'ils supportent bien est celle des bibliothèques de types, l'équivalent des métadonnées .NET. Utilisé par un compilateur pour savoir comment appeler les méthodes d'interface. L'EDI utilise une bibliothèque de types pour générer automatiquement la bibliothèque interop afin que vous puissiez directement créer la classe wrapper et appeler les méthodes à partir du code .NET.

Eh bien, c'est la bonne nouvelle. Les mauvaises nouvelles sont qu'il y a beaucoup d'interfaces COM autour qui n'utilisent pas les restrictions d'automatisation. Ils héritent généralement de IUnknown et utilisent des arguments de fonction qui ne se marient pas bien. Comme les structures. Un composant très grand et visible dans Windows qui est comme ceci est le shell. Windows Explorer.

C'est là IActiveDesktop s'intègre aussi bien, il est une interface shell et hérite de IUnknown. Il est déclaré dans le fichier d'en-tête SDK ShlObj.h, il n'y a même pas de fichier IDL pour cela. Et par conséquent aucun moyen d'obtenir une bibliothèque de types avec sa définition. Il utilise des types d'arguments incompatibles, comme LPCWSTR (un pointeur brut vers une chaîne) au lieu de BSTR. Et des pointeurs de structure comme LPCCOMPONENT et LPWALLPAPEROPT. Le support d'interopérabilité du CLR est impuissant à le faire correctement.

Utilisation de l'interface en C# est techniquement impossible, mais vous devez redéclarer l'interface. Très soigneusement, se tromper est très facile à faire. Le fait que le code source qui fait déjà cela est très difficile à trouver est un indice à quel point c'est difficile. Cela tombe carrément dans le «pas impossible, mais quel programmeur sensé veut maintenir le code comme ça». Le shell est le domaine du code C++ non géré. Et une équipe de programmeurs hardy, car le débogage des extensions shell est assez douloureux.