.Net e architetture plug-in

Question

In seguito alle discussioni di Jeff e Joel sulle architetture di plug-in.

I plug-in in C++ (utilizzando le DLL runtime caricate) sono sempre un po 'un problema. Devi fare un sacco di lavoro a terra per abilitarli e quindi il plugin deve anche essere scritto in C++, spesso anche con lo stesso compilatore. Gli oggetti COM e ActiveX hanno risolto alcuni di questi problemi, ma ne hanno introdotti alcuni.
Quindi aggiungere una interfaccia python a un'applicazione C++ è una grande quantità di lavoro.

Ho ragione nel ritenere che tutte le librerie (o assiemi o qualsiasi altra cosa le chiami) scritte in una lingua .Net possano sempre essere chiamate da un altro linguaggio .Net? E gli oggetti possono essere automaticamente trasferiti da un tipo di dati tra di loro?

Presumibilmente poiché tutti i linguaggi .Net utilizzano anche Winforms (o WPF) per la GUI, quindi l'accesso ai plug-in al gui dell'app principale è anche relativamente semplice.

Scusate se questo è un punto piuttosto ovvio, sono solo un vecchio programmatore C++. Ma la facilità di riutilizzare le librerie C++ esistenti via C++/CLI mi ha convinto che C# /. Net potrebbe valere la pena di ulteriori indagini.

Modifica - grazie, stavo cercando di discutere se i plugin fossero un motivo per andare .Net. Essere in grado di scrivere ironpython mentre i miei utenti aziendali sono in grado di scrivere un semplice plugin in VB e gli utenti tecnici sono in grado di creare qualcosa di intelligente in F # senza farmi fare altro lavoro sembrava una buona ragione per passare da C++

Answer 1

È corretto pensare che tutte le librerie (o assemblee o quello che chiamarli) scritti in una lingua .Net possono sempre essere chiamati da un altro linguaggio .Net? E gli oggetti possono essere automaticamente trasferiti da un tipo di dati tra di loro?

Sì. In .NET, la compatibilità tra più lingue è possibile grazie a CTS (offre una serie di tipi di dati comuni per l'utilizzo in tutti i linguaggi conformi a .NET e garantisce la compatibilità dei tipi) e CLS (Definisce una serie di standard minimi che tutti i compilatori di linguaggio .NET. deve essere conforme a, e quindi garantisce l'interoperabilità linguistica). Durante la compilazione, un codice sorgente di qualsiasi linguaggio conforme a .NET viene convertito in codice di lingua intermedia dal rispettivo compilatore di lingua. Poiché tutti gli assembly .NET (EXE o DLL) esistono come linguaggio intermedio, possono interagire tra loro. Tutti i linguaggi conformi a .NET utilizzano gli stessi tipi di dati e sono rappresentati solo come tipi .NET. Pertanto, se si utilizza int in C# o Integer in Visual Basic .NET, in IL è rappresentato come System.Int32. [Source]

Answer 2

Il problema principale con i plugin sotto. Net non è la capacità di chiamare il codice dalla dll del plugin (e di interagire con esso), ma problemi di sicurezza. Anche quelli possono essere risolti, puoi guardare qui (quelli di esempio che sono collegati dovrebbero anche presentare un semplice host + plug-in) How to create a Plugin Model in .NET with Sandbox?

E per l'interoperabilità tra i linguaggi .Net - non c'è problema.
Gui condivisi - L'ho fatto con Winforms, e non è stato molto difficile, anche se non so se sarebbe stato altrettanto semplice con WPF, ma non l'ho mai provato.

Answer 3

Sì, è possibile ottenere tutti loro attraverso Reflection

ci sono articoli su C# plug-in struttura come this one

Answer 4

Se stai cercando librerie di plug-in in.NET, ci sono un paio di opzioni che sono a conoscenza di:

• Da Microsoft c'è MEF
• Da Novell (Mono) c'è Mono.Addins

Entrambi sono open source, in modo da vedere come sono andati a creare un ambiente plug-in.