Référencement d'un assembly COM dans Visual Studio vs conversion d'un assembly COM via tlbimp.exe

Question

Lorsque j'importe un assembly COM (dll) dans un projet Visual Studio en l'ajoutant comme référence, je peux utiliser l'assembly runtime Common Language équivalent généré sans problème.

Toutefois, si j'essaie de convertir le même assembly COM en un assembly d'exécution de langage commun à l'aide de tlbimp, je suis confronté à toutes sortes de problèmes.

Existe-t-il un moyen de répliquer les paramètres que Visual Studio utilise avec tlbimp? Ou, en d'autres termes, existe-t-il un moyen de générer la même classe d'interopérabilité que visual studio en utilisant tlbimp?

Answer 1

J'ai trouvé la solution moi-même. Pour répliquer les paramètres que Visual Studio utilise avec tlbimp, vous devez simplement utiliser les indicateurs/out et/namespace.

Le drapeau de sortie est utilisé pour préfixer "Interop." sur le fichier généré et l'indicateur d'espace de noms est utilisé pour définir l'espace de noms par défaut sur le nom de l'assembly COM.

par exemple.

tlbimp /out:Interop.MyCom.dll /namespace:MyCom MyCom.dll 

Answer 2

il y a un peu plus, vous devez également utiliser l'option/sysarray sinon vous trouverez votre application plantera au hasard avec EngineExceptions soi-disant corruption de mémoire citant.

Ceci vous donnera un code identique à celui généré par visual studio.

Spécifiez le paramètre/namespace pour faire correspondre (cas compris) la clause de bibliothèque dans le fichier tlb. (peut utiliser oleview.exe pour voir les tlbs directement). L'avantage de l'utilisation de tlbimp, en particulier à partir d'un script msbuild, est que vous pouvez ensuite obtenir votre produit à construire correctement pour les cibles 64 et 32 ​​bits.

sinon vous finissez avec des cibles de construction 64 bits en utilisant les tlbs qui ont été les derniers regsvr32'd qui sont probablement les objets com 32 bits avec des interfaces 32 bits. Si vous faites 64 et 32 ​​bits, utilisez à la fois/reference et/tlbreference afin qu'il utilise les interops et tlbs que vous passez sur la ligne de commande plutôt que de pêcher dans le registre pour eux.