Architectures .Net et plugins

Question

Suite aux discussions de Jeff et Joel sur les architectures de plugins.

Les plugins en C++ (en utilisant des DLL chargées à l'exécution) sont toujours un peu pénibles. Vous devez faire beaucoup de travail pour les activer et ensuite le plugin doit aussi être écrit en C++, souvent même avec le même compilateur. Les objets COM et ActiveX ont résolu certains de ces problèmes mais en ont introduit quelques-uns.
Ensuite, ajouter une interface python à une application C++, c'est beaucoup de travail. Ai-je raison de penser que toutes les bibliothèques (ou assemblages ou tout ce que vous appelez) écrites dans un langage .Net peuvent toujours être appelées à partir d'un autre langage .Net? Et les objets et les types de données peuvent-ils être automatiquement transférés entre eux? Vraisemblablement, puisque tous les langages .Net utilisent aussi Winforms (ou WPF) pour le GUI, donner aux plugins l'accès au GUI de l'application principale est également relativement simple. Désolé si c'est un point plutôt évident que je suis juste un ancien programmeur C++. Mais la facilité de réutilisation des bibliothèques C++ existantes via C++/CLI m'a convaincu que C# /. Net pourrait valoir plus d'investigation. Edit - merci, je cherchais à discuter si les plugins étaient une raison d'aller. Net. Etre capable d'écrire ironpython tout en ayant mes utilisateurs professionnels capables d'écrire un simple plugin en VB et que les utilisateurs techniques puissent créer quelque chose de malin en F # sans que je fasse plus de travail semblait une bonne raison de changer de C++

Answer 1

Ai-je raison de penser que toutes les bibliothèques (ou ensembles ou tout ce que vous appelez-les) écrit dans un langage .Net peut toujours être appelé à partir d'un autre langage .Net? Et les objets et les types de données peuvent-ils être automatiquement transférés entre eux?

Oui. Dans .NET, la compatibilité inter-langages est possible grâce à CTS (offre un ensemble de types de données communs utilisables dans tous les langages compatibles .NET et assure la compatibilité des types) et CLS (définit un ensemble de normes minimales que tous les compilateurs de langage .NET doit se conformer à, et assure ainsi l'interopérabilité des langues). Pendant la compilation, un code source de n'importe quel langage compatible .NET est converti en code de langue intermédiaire par le compilateur de langue respectif. Comme tout l'assemblage .NET (EXE ou DLL) existe en langage intermédiaire, ils peuvent interopérer entre eux. Toutes les langues compatibles .NET utilisent les mêmes types de données et sont représentées uniquement en tant que types .NET. Par conséquent, que vous utilisiez int en C# ou Integer dans Visual Basic .NET, en IL, il est représenté par System.Int32.

Answer 2

Le problème principal avec les plugins sous .Net n'est pas la possibilité d'appeler le code de la DLL du plugin (et interagir avec elle), mais des problèmes de sécurité. Ceux-ci peuvent être résolus aussi, vous pouvez regarder ici (ceux de l'échantillon qui y est lié devraient également présenter un hôte très simple + plugin) How to create a Plugin Model in .NET with Sandbox?

Et pour l'interopérabilité entre les langages .Net - il n'y a pas de problème avec ça.
Gui partagé - J'ai fait ça avec Winforms, et ce n'était pas très dur, même si je ne sais pas si ce serait aussi facile avec WPF, je ne l'ai jamais essayé.

Answer 3

Ouais, vous pouvez réaliser toutes par Reflection

il y a des articles sur C# structure plug-in tels que this one

Answer 4

Si vous recherchez des bibliothèques de plug-ins dans.NET, il y a deux options que je suis au courant:

• De Microsoft, il est MEF
• de Novell (Mono), il y a Mono.Addins

Les deux sont open source, afin que vous puissiez voir comment ils sont allés créer un environnement de plug-in.