Quand les interfaces .Net sont-elles considérées comme équivalentes?

Question

J'écris du code pour implémenter une architecture de type plug-in. J'ai défini une interface, appelons-la IThing dans l'espace de noms MyStuff, pour le plug-in et j'ai également le code pour créer dynamiquement une instance du plug-in à partir d'une DLL. Mon code fait en regardant expose à travers des cours, des champs et des méthodes et tests en fin de compte ce qu'il trouve avec:

if (typeof(IThing).IsAssignableFrom(instType)) 

Tout cela est bien et fonctionne bien lorsque l'interface est mis en œuvre par quelque chose dans mon propre code, ce faisant référence à la assembly qui fournit la définition MyStuff.IThing.

Un autre développeur, dans une autre entreprise située dans un pays différent, écrit le composant enfichable.

J'ai envoyé la définition d'interface, c'est-à-dire la source C#, pour MyStuff.IThing au développeur et il l'a inclus dans son code.

Le problème que nous avons vu en premier est que son composant, même s'il a implémenté MyStuff.IThing, échouerait au test IsAssignableFrom ci-dessus. La raison de l'échec semble être qu'il a la définition d'interface dans un assemblage différent (bien sûr), même s'il a le même espace de noms et que la définition de l'interface n'a pas changé. La solution ici est assez simple, c'est que je lui envoie la DLL d'assemblage contenant l'interface.

Ma question est la suivante: étant donné que l'espace de noms correspond et que la définition de l'interface est identique, pourquoi l'assemblage dans lequel il se trouve est-il important? Si l'assembly A contient MyStuff.IThing avec exactement la même définition d'interface que MyStuff.IThing dans l'assembly B, pourquoi ces assemblages ne sont-ils pas interchangeables pour les besoins d'une application qui souhaite fonctionner avec une instance de MyStuff.IThing?

Answer 1

étant donné que l'espace de noms correspond et que la définition de l'interface est identique, pourquoi l'assemblage dans lequel il se trouve est-il important?

Le choix du traitement de ces interfaces comme équivalentes rendrait plus difficile de comparer les interfaces: plutôt que de comparer un ensemble fixe d'éléments (par exemple le nom qualifié et l'assemblage) CLR aurait besoin de comparer le nom qualifié, et liste de toutes les propriétés et de toutes les méthodes, avec leurs types d'arguments, qui seraient récursifs. Cela serait extrêmement lent, surtout si vous voulez le faire de manière cohérente et inclure des classes et struct s dans un schéma de comparaison similaire.

Remarque: lorsque vous partagez une DLL avec le développeur dans un autre pays, assurez-vous que votre assembly dispose d'un strong name. Cela garantirait que vous vous connectez tous les deux au même assembly et que vous détectiez les discordances au début. Par exemple, si vous modifiez votre interface, mais que l'autre développeur vous envoie un plug-in compilé avec une ancienne DLL, le plug-in échouera à se charger.

Answer 2

.NET ne vérifie pas les propriétés et leurs types et fait une conclusion pour les équivalences. Dans votre cas, la manière la plus simple serait de mettre vos interfaces dans une bibliothèque de classes et de partager cette DLL avec ceux qui souhaiteraient implémenter l'interface.