Комментарии 40
COMExport не подходит?
Это решение показалось для меня наиболее удобным. Честно сказать я никогда не пользовался COMExport
Честно говоря, не вижу ничего удобного в декомпиляции и правке ассемблерного кода. При автоматической сборке на билд-сервере вы проклянете это решение.
Никогда до этого не слышал про билд-серверы… Было очень сильное ограничение по времени, и первое решение осталось предпочтительным, что бы не тратить время
Ну, в таком случае рекомендую почитать про COM export. Для самообразования.
Как только закончу работу над проектом, сразу же займусь. Спасибо за рекомендацию.
Кстати, рекомендую на эту тему потом почитать у самого bobermaniac ;-) Он вроде писал об этом где-то в 2009.
как вариант — метод вызывается динамически через загруженный в процесс CLR. Но COM Export таки изящнее.
Плюсы загрузки CLR в неуправляемое хост-приложение в том, что можно наложить требуемые разрешения и прокинуть в домен приложения нужные интерфейсы до запуска управляемого кода. Ну и скилл повышает, да.
Плюсы загрузки CLR в неуправляемое хост-приложение в том, что можно наложить требуемые разрешения и прокинуть в домен приложения нужные интерфейсы до запуска управляемого кода. Ну и скилл повышает, да.
При автоматической сборке на билд-сервере вы проклянете это решение.Берём Mono.Cecil и автоматизируем процесс.
Еще можно посоветовать обратить внимание на Running Object Table, прекрасное средство взаимодействия процессов, неважно на чем написанных, встроенное в систему.
Вроде бы ilasm у 4го.нета (а вы используете его) уже сам шарит вставлять vtentry/vtfixup, нужно только export в теле функции указать и все.
К тому же это будет также работать с x64, где нужно int64 вместо int32 в vtentry указывать.
К тому же это будет также работать с x64, где нужно int64 вместо int32 в vtentry указывать.
Вот интересный проектик sites.google.com/site/robertgiesecke/. Делает то же что и вы только автоматом :)
Хотелось бы поподробнее на счет «export в теле функции указать». Я не нашел решения.
Делаете то же самое что и сейчас (вы же добавляете export [N] as Name), только не нужно добавлять vtentry и vtfixup в начале. Щас поищу.
Спасибо, эта статья мне не попадалась…
Используемый вам метод, а также другие способы связки MQL5 и managed кода расписаны в замечательной статье
Я в том году за статью об этом методе получил инвайт =).
Потом вышла более продуманная и расписанная тут: www.gotdotnet.ru/blogs/RaveNoX/7202/
Потом вышла более продуманная и расписанная тут: www.gotdotnet.ru/blogs/RaveNoX/7202/
Ну вот народ автоматом всё делает, статья 2006 года How to Automate Exporting .NET Function to Unmanaged Programs
НЛО прилетело и опубликовало эту надпись здесь
Там внутри обычный COFF/PE с IL-кодом внутри одной из секций. При подгрузке такой библиотеки виндовый загрузчик заодно подгружает и CLR (mscoree.dll в таблице импоорта), который уже и выполняет JIT-компиляцию. Самой же дотнетной библиотеке никто не запрещает содержать и native code.
НЛО прилетело и опубликовало эту надпись здесь
Когда mscoree будет выполнять компиляцию?
Её пнут из DllMain, вероятно.
mscoree в момент своей загрузки поправит таблицу экспорта в загруженной сборке?Зачем править таблицу экспорта, если можно сразу при компиляции сделать переходники, пинающие mscoree?
Вообще, возьмите IDA да посмотрите, у меня её под рукой нет.
Есть же С++ CLI, в котором можно стандартными средставми указать ф-ии для экспорта и вызвать управляемую шарповую дллку. Зачем эти хаки?
Не резон ради одной функции на C# писать оболочку на C++, а только .Net было обязательным требованием заказчика
Пару часов поисков в интернете...
А пару часов гуглить — ок?
И в итоге получить вместо нормального решения хак, требующий кучу ручной работы при пересборке.
Я повторюсь, у меня в планах было написать приложение для автоматизации этого процесса, но поняв что библиотеку мне не нужно будет 100 раз пересобирать, я остановил свой выбор на этом методе
Статья только путать людей. Это курьез, не более того, не надо это использовать нигде.
С чего вы решили что вам надо будет что то пересобрать 100 раз? Два проекта просто будет которые сами скомпилируются.
У вас в руках и .h будет нормальный и .lib, в случае изменения интерфейсов у вас при компиляции будут ошибки возникать а не в рантайме. А такие решения как у вас вместо временных обычно становятся постоянными. Посмотрю я на вас или кого-то кто будет с этим в будущем разбираться если вы забудете сколько у вас параметров в функциях.
С чего вы решили что вам надо будет что то пересобрать 100 раз? Два проекта просто будет которые сами скомпилируются.
У вас в руках и .h будет нормальный и .lib, в случае изменения интерфейсов у вас при компиляции будут ошибки возникать а не в рантайме. А такие решения как у вас вместо временных обычно становятся постоянными. Посмотрю я на вас или кого-то кто будет с этим в будущем разбираться если вы забудете сколько у вас параметров в функциях.
С++/CLI — это один из языков .NET, вполне возможно было просто добавить managed C++ проект с необходимыми интерфейсами, это гораздо проще, чем каждый раз править IL.
Почему не COM? Платформа другая?
Кстати говоря. Может, я неправильно понял проблему, тогда поправьте, пожалуйста.
Есть библиотека на C#, нужно пользовать её функции в неуправляемом коде.
В таком случае берем таблицу типов из dll и подключаем эту dll в неуправляемом коде, примерно так:
Насколько я понимаю, это решает задачу.
Есть библиотека на C#, нужно пользовать её функции в неуправляемом коде.
В таком случае берем таблицу типов из dll и подключаем эту dll в неуправляемом коде, примерно так:
- #import "SupportLibrary.tlb" raw_interfaces_only
- using namespace SupportLibrary
Насколько я понимаю, это решает задачу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Делаем библиотеку написанную на .Net понятной для Unmanaged кода