Советы по использованию родной C ++ DLL или нет: PINVOKE & Marshaling? - PullRequest
2 голосов
/ 29 мая 2010

Какой лучший способ сделать это ....?

У меня есть некоторый собственный код C ++, который использует много вызовов Win32 вместе с байтовыми буферами (выделенными с помощью HeapAlloc). Я хотел бы расширить код и создать графический интерфейс C # ... и, возможно, позже использовать базовый графический интерфейс Win32 (для использования там, где нет поддержки .Net и ограниченной поддержки MFC).

(A) Я мог бы просто переписать код на C # и использовать несколько PINVOKEs .... но даже с PINVOKES в отдельном классе код выглядит беспорядочным со всем маршалингом. Я также переписываю много кода.

(B) Я мог бы создать собственную C ++ DLL и использовать PINVOKE для компоновки собственных структур данных. Я предполагаю, что могу включить нативную C ++ DLL / LIB в проект с использованием C #?

(C) Создание DLL в смешанном режиме (собственный класс C ++ плюс управляемый класс ref). Я предполагаю, что это облегчит использование управляемого класса ref в C # ...... но так ли это? Будет ли управляемый класс обрабатывать весь маршалинг? Могу ли я использовать эту DLL в смешанном режиме на платформе без .Net (т.е. по-прежнему иметь доступ к собственному неуправляемому компоненту C ++) или я могу ограничиться только платформой .Net.

Одна вещь, которая беспокоит меня в каждом из этих вариантов, это все сортировка. Лучше ли создать управляемую структуру данных (массив, строку и т. Д.) И передать ее в собственный класс C ++ или наоборот?

Любые идеи о том, что считается лучшей практикой ...?

UPDATE: Я знаю, что могу переписать собственный код C ++ с нуля, но это означает дублирование кода и не позволяет мне легко повторно использовать любые обновления кода с любым приложением Win32. Что меня больше всего беспокоит, так это лучший способ сопоставить различные данные между управляемым и неуправляемым миром. Для меня DLL в смешанном режиме выглядит наиболее гибким вариантом, но я бы хотел по-другому взглянуть на возможные подводные камни.

Ответы [ 2 ]

1 голос
/ 29 мая 2010

Почему бы просто не использовать .NET напрямую? Мне кажется, что ваша проблема возникает из-за того, что вы зависите от исходной нативной библиотеки, но вы не упоминаете, что это не может быть просто сделано заново в .NET.

Что касается встроенного взаимодействия .NET, PInvoke грязный, но работает. Я бы пошел с этим, если вы не можете изменить исходную DLL в .NET.

0 голосов
/ 21 июня 2010

Опция C дает вам наименьшую работу, если маршалинг оказывается простым и легким для фреймворка (все ли в порядке?). Это также дает вам место, чтобы подключить ваш собственный маршалинг. Я написал что-то об этом маршалинге давным-давно между типами дат и т. Д., Но я думаю, что сегодня я бы написал перегрузку marshal_as <> между управляемыми и нативными типами. Это было бы самое элегантное решение, а также наименьшее количество кода.

Обновление: нашел мою старую статью - это было для PInvoke. http://codeguru.earthweb.com/columns/kate/article.php/c4867/

...