Lorsque vous interfacez un objet COM du code .NET, VS crée une DLL Interop, avec des classes Interop.
Exemple: P>
Vous avez un foo.dll les implémente une bibliothèque COM. Inclut une implémentation de l'interface COM "ibar". Vous ajoutez une référence à FOO.DLL à un projet .NET. Dans / bin, vous verrez une interop.foolib.dll. Dans le navigateur d'objets, vous verrez interop.foolib, sous que vous verrez Pulibib, sous que vous verrez barclass, sous cela, vous verrez des types de base, sous ce bar et de cette barrette. P>
Dans votre code .NET, lorsque vous déclarez une variable, vous pouvez taper POLIBIB, et IntelliSense vous donnera les options de bar ou de barclass (). P>
de ce que j'ai compris, ça n'a pas d'importance que vous utilisez dans une déclaration de variable, mais ce qui compte beaucoup que vous avez utilisé pour son constructeur. P>
C'est-à-dire, tous deux devraient fonctionner: P>
[ComImport, CoClass(typeof(BarClass)), Guid("...")]
public interface Bar : IBar
{
}
3 Réponses :
Grande question. Beaucoup de gens sont surpris que cela fonctionne du tout parce que la barre est une interface et vous ne devriez sûrement pas pouvoir créer une nouvelle instance d'une interface! Mais même si je ne semble pas sembler trouver des détails de la mise en œuvre, je me souviens de lire dans le livre Interop de Adam Nathan de Nathan que C # constitue une exception spéciale pour les interfaces COM marquées d'un coclassattribute et transforme l'appel en une instanciation de la coclasse. < / p>
Mais je ne sais pas pourquoi cela fonctionnerait parfois et parfois ne fonctionnerait pas.
Le constructeur de barre () en principe devrait renvoyer l'interface explicitement au lieu de l'objet de la classe. Je ne peux pas comprendre comment .Net soutient la construction d'une interface !?
Dans tous les cas, vous pouvez cliquer sur le constructeur de la barre () et appuyez sur Shift-F12. Cela vous montrera partout ailleurs dans le code où ce constructeur est utilisé. Je ne peux pas penser à un moyen d'empêcher un utilisateur d'appeler ce constructeur par inadvertance.
Avez-vous lu la discussion dans Cette question ? Il discute exactement de cette question que je pense.
Il discute de la question, mais cela n'explique pas pourquoi cela fonctionnerait d'une seule machine et d'une manière différente sur une autre. Pourrions-nous faire face à un bogue dans .NET qui a été corrigé dans un pack de services qui n'a pas été installé?
Compte tenu de suffisamment de temps, vous pouvez probablement identifier la raison, cela pourrait très bien être un SP / BugFix OS SP / BUCKFIX, ou quelque chose de complètement différent ...: - / Je ne peux pas faire plus que vous pouvez utiliser votre question!