Взаимодействие managed и unmanaged кода

[kekekeks]

А ещё можно не плодить тонны лишних сущностей создающих проблемы переносимости даже в Windows (32 и 64 бита), и использовать встроенную в CLI инструкцию вызова функции по произвольному указателю. Но, конечно, ни у кого нет времени, чтобы разбираться с этим, лучше ещё раз соорудить промежуточную неуправляемую заглушку, ведь там всё просто и понятно.

[kekekeks]

Тьфу. Пост не читай@Сразу отвечай. Извините.

[akaBd]

Честно говоря, работать с инcтрукциями MSIL приходилось очень мало. Вы предлогаете перейти к программированию на низком уровне?

лучше ещё раз соорудить промежуточную неуправляемую заглушку, ведь там всё просто и понятно

Имхо это действительно понятно и просто.

[braindamaged]

А зачем нужен вот этот вот средний розовый квадратик на с++/CLI?

Можно же просто в желтом квадрате, который «managed dll» объявить кокласс-переходник, и его инстанциировать в native dll (синий квадрат)?

[akaBd]

Можно же просто в желтом квадрате, который «managed dll» объявить кокласс-переходник, и его инстанциировать в native dll (синий квадрат)?

Вы правы, действительно можно было так сделать. Т.е. объявить интерфейс, класс к нему и создать в native dll. И все должно действительно работать.
Но в данной статье показано, что можно реализовать «красивое» взаимодействие именно без помощи СОМа.
Т.е. сама цель была не использовать СОМ.

p.s. не использовать потому, что у стороннего приложения (ArchiCAD) есть серьезная проблема с освобождением ресурсом после использования СОМа (валится напрочь)

[braindamaged]

Эээ… Так ComVisible и использование tlb — это уже обращение к COM-маршаллеру, так что обойтись без COM не удалось.

Насчёт проблем с освобождением ресурсов — могу посоветовать их решить ручным управлением ресурсами в unmanaged dll (синий блок) и запуском COM-подсистемы в режиме out-of-process.

[akaBd]

Эээ… Так ComVisible и использование tlb — это уже обращение к COM-маршаллеру, так что обойтись без COM не удалось.

tlb использовался для доступа с структурам на стороне unmanaged dll. Можно это убрать. Т.е. создать структуры на 2ух сторонах: на стороне managed и unmanaged dll и потом приводить их (главное чтобы размер совпадал).

Насчёт проблем с освобождением ресурсов — могу посоветовать их решить ручным управлением ресурсами в unmanaged dll (синий блок) и запуском COM-подсистемы в режиме out-of-process.

Возможно Вы правы. Насколько я помню (утверждать не могу, довольно давно было дело) мы пробовали запускать COM в отдельном процессе, проблему это не решило (с ArchiCADом). Хотя в другом в другом продукте при взаимодействии уже с другим приложением предложенная вами архитектура работает без проблем.

[akaBd]

Можно это убрать. Т.е. создать структуры на 2ух сторонах: на стороне managed и unmanaged dll и потом приводить их (главное чтобы размер совпадал).

но у нас используется именно такая модель, т.е. структуры описаны на стороне managed. Так как они очень объемные (количество данных большое) и проще поддерживать 1 версию структур чем создавать копию на стороне unmanaged dll.

[gouranga]

Я, к сожалению, не знаком с ArchiCAD, но я не уверен, что утверждение:

Библиотеку (plugin) можно реализовать только на C\C++.

верно.

Если я прав, то почему бы вообще не отказаться от unmanaged-прослойки и сразу в бизнес-приложении не реализовать все интерфейсы взаимодействия с плагин-системой ArchiCAD? И да, это будет работать без COM. По крайней мере должно. :o)

Единственная сложность данного подхода — правильный экспорт managed-методов.
В MSIL есть нужная инструкция:

.export [<ordinal>] as <export_name>

, а в Visual Studio встроенных средств/атрибутов для этого не предусмотрено. Зато у нас есть много кода и описаний от разных умельцев: раз, два, три и четыре. Последний использует Cecil и даже имеет шаблон-проект.

Я лично сделал wcx-плагин для Total Commander используя код из второй статьи (методы действительно экспортированы) — все отлично работает и по сей день. :)

[Weageoo]

четыре — и этим всё сказано!

[akaBd]

Это магия…

[gouranga]

это действительно есть, и оно даже работает, и оно действительно похоже на магию. при том, если мне память не изменяет, с самой первой версии.

погуглите Serge Lidin, у него пара книг про .Net IL и в обеих есть раздел Interoperation. обе книги в целом очень умные, и даже местами сложноваты, но про взаимодействие managed/unmanaged там все ооочень досконально расписано. лучше вообще обе книжки прочитать или, хотя бы, последнюю. :-)

черт подери, может статью написать про этот способ взаимодействия? получается только его еще на хабре не описали. получится правда скорее перевод, нежели нечто свое. :-)

[akaBd]

Я, к сожалению, не знаком с ArchiCAD, но я не уверен, что утверждение:

Библиотеку (plugin) можно реализовать только на C\C++.
верно.

хмм, ArchiCAD использует собственные генераторы ресурсов… но методом не так много необходимо экспортировать, может и можно подменить C\C++ на managed…

а в Visual Studio встроенных средств/атрибутов для этого не предусмотрено. Зато у нас есть много кода и описаний от разных умельцев: раз, два, три и четыре. Последний использует Cecil и даже имеет шаблон-проект.

Я лично сделал wcx-плагин для Total Commander используя код из второй статьи (методы действительно экспортированы) — все отлично работает и по сей день. :)

Да, помню, когда-то я присматривался к вашему варианту. (вспомнился пункт три<a/>).
Но имхо — метод, что я описал в статье — гораздо проще и не требует особой магии и танцев с бубном.

[akaBd]

извиняюсь, тэг неправильно закрыл.

[gouranga]

ну, танцев с бубном там нет: помечаем нужные статические методы атрибутом DllExport, устанавливаем пост-таргет для проекта и все. :-)
в любом случае, спасибо за статью. опыт managed&unmanaged-интеграции полезен.

[akaBd]

пожалуйста, спасибо за советы

[The_HeBckOi]

Используем похожий метод путем mixed dll(managed&unmanaged) для интеграции с AutoCAD. Только структуры данных конвертируем «в ручную»