.Net и плагины архитектуры

Question

Следуя обсуждениям Джеффа и Джоэля о плагиновых архитектурах.

Плагины на C++ (с использованием загружаемых DLL-файлов во время выполнения) всегда немного больны. Вы должны сделать много работы на земле, чтобы включить их, а затем плагин также должен быть написан на C++, часто даже с тем же компилятором. COM-объекты и ActiveX решили некоторые из этих проблем, но представили несколько своих.
Затем, чтобы сказать, что интерфейс python для приложения на C++ - это большой объем работы.

Правильно ли я полагаю, что все библиотеки (или сборки или то, что вы их называете), написанные на одном языке .Net, всегда могут быть вызваны с другого языка .Net? И может ли объект данных автоматически переноситься между ними?

Предположительно, поскольку все языки .Net также используют Winforms (или WPF) для gui, а затем предоставление плагинов доступа к gui основного приложения также относительно просто.

Извините, если это довольно очевидный момент, я просто старомодный программист на С ++. Но простота повторного использования существующих библиотек C++ через C++/CLI убедила меня в том, что C# /. Net может стоить большего внимания.

Редактировать - спасибо, я хотел обсудить, были ли плагины причиной для перехода .Net. Будучи в состоянии написать ironpython, когда мои бизнес-пользователи могут написать простой плагин в VB, и технические пользователи смогут создавать что-то умное в F #, если я не сделаю больше работы, было хорошей причиной для перехода с C++

Answer 1

Я правильно думать, что все библиотеки (или сборки или что вы называть их), написанные на одном языке .Net всегда можно вызывать с другого языка .Net? И может ли объект данных автоматически переноситься между ними?

Да. В .NET кросс-языковая совместимость возможна из-за CTS (Предлагает набор общих типов данных для использования на всех совместимых с .NET языках и обеспечивает совместимость типов) и CLS (Определяет набор минимальных стандартов, которые все компиляторы .NET-языка должны соответствовать и, следовательно, обеспечивать совместимость языков). Во время компиляции исходный код любого .NET-совместимого языка преобразуется в код промежуточного языка соответствующим компилятором языка. Поскольку вся сборка .NET (EXE или DLL) существует как промежуточный язык, они могут взаимодействовать между ними. Все языки, совместимые с .NET, используют одни и те же типы данных и представлены только как типы .NET. Поэтому, если вы используете int в C# или Integer в Visual Basic .NET, в IL он представлен как System.Int32. [Source]

Answer 2

Основная проблема с плагинами под .Net - это не возможность вызывать код из dll плагина (и взаимодействовать с ним), но проблемы с безопасностью. Они также могут быть решены, вы можете посмотреть здесь (те, которые связаны между собой, также должны содержать очень простой хост + плагин) How to create a Plugin Model in .NET with Sandbox?

И для взаимодействия между .Net-языками - нет проблем с этим.
Общий gui - я сделал это с Winforms, и это было не очень сложно, хотя я не знаю, было бы так же легко в WPF, но я никогда не пробовал.

Answer 3

Да, вы можете достичь всего, из них через Reflection

есть статьи о C# вставной конструкции, такие как this one

Answer 4

Если вы ищете библиотеки плагинов в.NET, есть несколько вариантов, я знаю:

• От Microsoft есть MEF
• От Novell (Mono) есть Mono.Addins

Оба с открытым исходным кодом, так что вы можете увидеть как они начали создавать среду подключаемого модуля.