Suivre les discussions sur les architectures du plugin de Jeff et Joel.
Les plugins en C ++ (à l'aide des dlls chargés d'exécution) sont toujours un peu douloureux. Vous devez faire beaucoup de travail de terre pour leur permettre, puis le plugin doit également ê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 introduit quelques-uns des leurs.
Ensuite, pour ajouter une interface Python, à une application C ++ est une grande quantité de travail.
suis-je correct en pensant que toutes les bibliothèques (ou assemblages ou quoi que vous appelle les appelez) écrit dans une langue .NET peut toujours être appelé à partir d'une autre langue .NET? Et peut-il obtenir des types de données être automatiquement transférés entre eux?
Vraisemblablement puisque toutes les langues .NET utilisent également des winforms (ou WPF) pour l'interface graphique, puis donnant accès à des plugins à l'interface graphique de l'application principale est également relativement simple.
Désolé, s'il s'agit d'un point assez évident, je ne suis qu'un seul 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. Être capable d'écrire Ironpython tout en ayant des utilisateurs d'entreprise capables d'écrire un plugin simple dans VB et les utilisateurs techniques pour que les utilisateurs techniques puissent embarrasser quelque chose d'intelligent dans F # sans que je fais plus de travail semblait une bonne raison de passer de C ++
4 Réponses :
Le problème principal avec les plugins sous .NET n'est pas la possibilité d'appeler le code de la DLL du plugin (et de l'interporation avec elle), mais des problèmes de sécurité. Ceux-ci peuvent également être résolus, vous pouvez regarder ici (des échantillons qui sont liés là-bas doivent également présenter un plugin hôte + simple) Comment créer un modèle de plug-in en .NET avec Sandbox?
et pour l'interopérabilité entre les langues .NET - il n'y a aucun problème avec ça.
Gui partagée - Je l'ai fait avec Winforms, et ce n'était pas très difficile, même si je ne sais pas si ce serait aussi aussi facile sous WPF, je n'ai jamais essayé cependant.
suis-je correct en pensant que toutes les bibliothèques (ou assemblages ou quoi que vous appelle les appelez) écrit dans une langue .NET peut toujours être appelé à partir d'une autre langue .NET? Et peut-il obtenir des types de données être automatiquement transférés entre eux?
Oui. En .NET, la compatibilité transversale est possible en raison de CTS (offre un ensemble de types de données communs pour une utilisation sur toutes les langues conformes .NET et assure une compatibilité de type) et CLS (définit un ensemble de normes minimales que tous les compilateurs de langue .NET doit être conforme à et assure ainsi l'interopérabilité de la langue). Pendant la compilation, un code source de toute langue conforme à .NET est converti en code de langue intermédiaire par le compilateur de langue respectif. Comme tous les assemblages .NET (EXE ou DLL) existe comme langue intermédiaire, ils peuvent interagir entre eux. Toutes les langues confortables .NET utilisent les mêmes types de données et sont représentés uniquement en tant que types .NET uniquement. Par conséquent, si vous utilisez INT en C # ou entier dans Visual Basic .NET, en IL, il est représenté comme système.int32. [ source ]
+1 De grands commentaires sur le fonctionnement de l'IL. Je n'avais pas vraiment pensé aux utilisateurs finaux d'écrire des plugins avec autre chose que c #.
Il y a une petite capture - des différences de mots-clés. C # a une prise en charge intégrée pour les noms de variables / membres qui sont des mots-clés (par exemple, @class , @if , @while etc.), Mais toutes les autres langues ne font pas. Si vous utilisez un nom, qui est un mot clé dans une autre langue .NET, vous pouvez avoir des problèmes d'accès à ce membre. Je suppose que c'est un cas rare, mais il convient de savoir certainement.
Si vous recherchez des bibliothèques Plug-ins dans .NET, il y a quelques options que je suis au courant:
Les deux sont open source, vous pouvez donc voir comment ils sont allés créer un environnement plug-in.
Merci que c'était plus une discussion sur si les plugins étaient un avantage majeur de .NET