как вызвать методы c # (mono, .net), делегаты из собственного c

Ваш код C может определять функции для регистрации обратных вызовов. Код C # может вызывать эти функции P / Invoke и передавать управляемые делегаты в качестве аргументов. Код маршаллинга прозрачно преобразует их в указатели функций C.

В качестве альтернативы, подходя к нему со стороны C, вы можете использовать API встраивания Mono для загрузки сборок, поиска MonoMethods и их вызова.

Использование API встраивания намного сложнее. Если ваша точка входа находится на C, вам придется использовать API встраивания, но, вероятно, проще просто написать управляемый метод для регистрации обратного вызова и любой другой управляемой настройки, тогда вам нужно только загрузить и вызвать этот единственный метод из кода C.

На сайте MSDN есть Обзор взаимодействия управляемого / неуправляемого кода, который может пролить свет для вас. Отрывок ниже:

Прямой доступ к управляемому API

Если неуправляемый клиент написан на C ++, его можно скомпилировать с помощью компилятора Visual Studio .NET C ++ как «образ в смешанном режиме». После этого неуправляемый клиент может напрямую обращаться к любому управляемому API. Однако некоторые правила кодирования действительно применяются к доступу к управляемым объектам из неуправляемого кода; см. документацию по C ++ для получения более подробной информации.

Прямой доступ является предпочтительным вариантом, поскольку он не требует особого внимания со стороны разработчиков управляемого API. Они могут разрабатывать свой управляемый API в соответствии с руководящими принципами проектирования управляемых API (DG) и быть уверенными, что API по-прежнему будет доступен для неуправляемых вызывающих абонентов.

Представление управляемого API как COM API

Каждый общедоступный управляемый класс может быть предоставлен неуправляемым клиентам через COM-взаимодействие. Этот процесс очень легко реализовать, потому что уровень взаимодействия COM берет на себя всю работу по подключению COM. Таким образом, например, каждый управляемый класс, по-видимому, реализует IUnknown, IDispatch, ISupportErrorInfo и несколько других стандартных COM-интерфейсов.

Несмотря на то, что представить управляемые API-интерфейсы как COM-API легко, модели управляемых и COM-объектов сильно различаются. Следовательно, предоставление управляемого API-интерфейса COM всегда должно быть явным дизайнерским решением. Некоторые функции, доступные в управляемом мире, не имеют аналогов в мире COM и не могут использоваться клиентами COM. Из-за этого часто возникает противоречие между руководящими принципами разработки управляемого API (DG) и совместимостью с COM.

Если клиенты COM важны, напишите свой управляемый API в соответствии с рекомендациями по проектированию управляемого API, а затем напишите тонкую, удобную для COM управляемую оболочку вокруг управляемого API, которая будет доступна для COM.

Представление управляемого API как плоского API

Иногда неуправляемые клиенты не могут использовать COM. Например, они могут уже быть написаны для использования плоских API и не могут быть изменены или перекомпилированы. C ++ - единственный язык высокого уровня, который позволяет предоставлять управляемые API в виде плоских API. Сделать это не так просто, как представить управляемый API в виде COM API. Это очень продвинутый метод, требующий глубоких знаний о взаимодействии C ++ и различиях между управляемым и неуправляемым мирами.

Предоставляйте управляемый API как плоский API только в случае крайней необходимости. Если у вас нет выбора, обязательно проверьте документацию по C ++ и полностью осознайте все ограничения.

Вот решение. Для вызова функции C # из C используется атрибут [DllExport] (противоположный P / Invoke DllImport). https://sites.google.com/site/robertgiesecke/Home/uploads/unmanagedexports