Comments 17
А ещё можно не плодить тонны лишних сущностей создающих проблемы переносимости даже в Windows (32 и 64 бита), и использовать встроенную в CLI инструкцию вызова функции по произвольному указателю. Но, конечно, ни у кого нет времени, чтобы разбираться с этим, лучше ещё раз соорудить промежуточную неуправляемую заглушку, ведь там всё просто и понятно.
Тьфу. Пост не читай@Сразу отвечай. Извините.
Честно говоря, работать с инcтрукциями MSIL приходилось очень мало. Вы предлогаете перейти к программированию на низком уровне?
Имхо это действительно понятно и просто.
лучше ещё раз соорудить промежуточную неуправляемую заглушку, ведь там всё просто и понятно
Имхо это действительно понятно и просто.
А зачем нужен вот этот вот средний розовый квадратик на с++/CLI?
Можно же просто в желтом квадрате, который «managed dll» объявить кокласс-переходник, и его инстанциировать в native dll (синий квадрат)?
Можно же просто в желтом квадрате, который «managed dll» объявить кокласс-переходник, и его инстанциировать в native dll (синий квадрат)?
Можно же просто в желтом квадрате, который «managed dll» объявить кокласс-переходник, и его инстанциировать в native dll (синий квадрат)?
Вы правы, действительно можно было так сделать. Т.е. объявить интерфейс, класс к нему и создать в native dll. И все должно действительно работать.
Но в данной статье показано, что можно реализовать «красивое» взаимодействие именно без помощи СОМа.
Т.е. сама цель была не использовать СОМ.
p.s. не использовать потому, что у стороннего приложения (ArchiCAD) есть серьезная проблема с освобождением ресурсом после использования СОМа (валится напрочь)
Эээ… Так ComVisible и использование tlb — это уже обращение к COM-маршаллеру, так что обойтись без COM не удалось.
Насчёт проблем с освобождением ресурсов — могу посоветовать их решить ручным управлением ресурсами в unmanaged dll (синий блок) и запуском COM-подсистемы в режиме out-of-process.
Насчёт проблем с освобождением ресурсов — могу посоветовать их решить ручным управлением ресурсами в unmanaged dll (синий блок) и запуском COM-подсистемы в режиме out-of-process.
Эээ… Так ComVisible и использование tlb — это уже обращение к COM-маршаллеру, так что обойтись без COM не удалось.
tlb использовался для доступа с структурам на стороне unmanaged dll. Можно это убрать. Т.е. создать структуры на 2ух сторонах: на стороне managed и unmanaged dll и потом приводить их (главное чтобы размер совпадал).
Насчёт проблем с освобождением ресурсов — могу посоветовать их решить ручным управлением ресурсами в unmanaged dll (синий блок) и запуском COM-подсистемы в режиме out-of-process.
Возможно Вы правы. Насколько я помню (утверждать не могу, довольно давно было дело) мы пробовали запускать COM в отдельном процессе, проблему это не решило (с ArchiCADом). Хотя в другом в другом продукте при взаимодействии уже с другим приложением предложенная вами архитектура работает без проблем.
Можно это убрать. Т.е. создать структуры на 2ух сторонах: на стороне managed и unmanaged dll и потом приводить их (главное чтобы размер совпадал).
но у нас используется именно такая модель, т.е. структуры описаны на стороне managed. Так как они очень объемные (количество данных большое) и проще поддерживать 1 версию структур чем создавать копию на стороне unmanaged dll.
Я, к сожалению, не знаком с ArchiCAD, но я не уверен, что утверждение:
верно.
Если я прав, то почему бы вообще не отказаться от unmanaged-прослойки и сразу в бизнес-приложении не реализовать все интерфейсы взаимодействия с плагин-системой ArchiCAD? И да, это будет работать без COM. По крайней мере должно. :o)
Единственная сложность данного подхода — правильный экспорт managed-методов.
В MSIL есть нужная инструкция:
, а в Visual Studio встроенных средств/атрибутов для этого не предусмотрено. Зато у нас есть много кода и описаний от разных умельцев: раз, два, три и четыре. Последний использует Cecil и даже имеет шаблон-проект.
Я лично сделал wcx-плагин для Total Commander используя код из второй статьи (методы действительно экспортированы) — все отлично работает и по сей день. :)
Библиотеку (plugin) можно реализовать только на C\C++.
верно.
Если я прав, то почему бы вообще не отказаться от unmanaged-прослойки и сразу в бизнес-приложении не реализовать все интерфейсы взаимодействия с плагин-системой ArchiCAD? И да, это будет работать без COM. По крайней мере должно. :o)
Единственная сложность данного подхода — правильный экспорт managed-методов.
В MSIL есть нужная инструкция:
.export [<ordinal>] as <export_name>, а в Visual Studio встроенных средств/атрибутов для этого не предусмотрено. Зато у нас есть много кода и описаний от разных умельцев: раз, два, три и четыре. Последний использует Cecil и даже имеет шаблон-проект.
Я лично сделал wcx-плагин для Total Commander используя код из второй статьи (методы действительно экспортированы) — все отлично работает и по сей день. :)
четыре — и этим всё сказано!
Это магия…
это действительно есть, и оно даже работает, и оно действительно похоже на магию. при том, если мне память не изменяет, с самой первой версии.
погуглите Serge Lidin, у него пара книг про .Net IL и в обеих есть раздел Interoperation. обе книги в целом очень умные, и даже местами сложноваты, но про взаимодействие managed/unmanaged там все ооочень досконально расписано. лучше вообще обе книжки прочитать или, хотя бы, последнюю. :-)
черт подери, может статью написать про этот способ взаимодействия? получается только его еще на хабре не описали. получится правда скорее перевод, нежели нечто свое. :-)
погуглите Serge Lidin, у него пара книг про .Net IL и в обеих есть раздел Interoperation. обе книги в целом очень умные, и даже местами сложноваты, но про взаимодействие managed/unmanaged там все ооочень досконально расписано. лучше вообще обе книжки прочитать или, хотя бы, последнюю. :-)
черт подери, может статью написать про этот способ взаимодействия? получается только его еще на хабре не описали. получится правда скорее перевод, нежели нечто свое. :-)
Я, к сожалению, не знаком с ArchiCAD, но я не уверен, что утверждение:
Библиотеку (plugin) можно реализовать только на C\C++.
верно.
хмм, ArchiCAD использует собственные генераторы ресурсов… но методом не так много необходимо экспортировать, может и можно подменить C\C++ на managed…
а в Visual Studio встроенных средств/атрибутов для этого не предусмотрено. Зато у нас есть много кода и описаний от разных умельцев: раз, два, три и четыре. Последний использует Cecil и даже имеет шаблон-проект.
Я лично сделал wcx-плагин для Total Commander используя код из второй статьи (методы действительно экспортированы) — все отлично работает и по сей день. :)
Да, помню, когда-то я присматривался к вашему варианту. (вспомнился пункт три<a/>).
Но имхо — метод, что я описал в статье — гораздо проще и не требует особой магии и танцев с бубном.
Используем похожий метод путем mixed dll(managed&unmanaged) для интеграции с AutoCAD. Только структуры данных конвертируем «в ручную»
Sign up to leave a comment.
Взаимодействие managed и unmanaged кода