Каково концептуально типовое решение для такой связки?
Импорт АПИ-функций мне не нравится. Для решения какой-нибудь задачи типа внедрения dll в адресное пространство чужого процесса или работа с хуками клавы\мыши куда приятнее пользоваться родным кодом, чем импортировать кучу функций. Допустим, для последней задачи можно использовать Managed DX, но не всегда все так просто.
Самое простое — сделать COM-объект Stuff, реализовать в нем все, что надо, и пользоваться через Interop (дает комовский реюз, помимо прочего). Еще можно написать managed компоненту на MC++.
А нет ли способа смешивать в одном csproj'е код шарпа и код MC++, чтобы __gc-классы предоставляли интерфейс для вызовов из шарпа с unmanaged-имплементацией (WinAPI)? Может, решение очевидно, но я не дотумкал?
А>Для решения какой-нибудь задачи типа внедрения dll в адресное пространство чужого процесса или работа с хуками клавы\мыши куда приятнее пользоваться родным кодом, чем импортировать кучу функций.
С трудом представляю, как для задачи внедрения можно применить managed code. Разве что внедрить загрузчик, поднять там хост и далее загружать сборку с managed кодом. Только вот зачем все это?
А>Самое простое — сделать COM-объект Stuff, реализовать в нем все, что надо, и пользоваться через Interop (дает комовский реюз, помимо прочего).
Честно говоря, простота такого решения кажется обманчивой. Ничего кроме написания лишнего кода я хорошего в COMе не вижу, и развития его не предвидится. Реюз же хорош ровно в том случае, если изначально нужен COM-объект (скажем, для использования в legacy коде). Делать же новое приложение на COMе непонятно зачем надо.
А>Еще можно написать managed компоненту на MC++.
Компоненту -- в смысле класс? Да можно. Подходящее по затратам решение, если API сложное и на C# через pinvoke тяжело получается.
А>А нет ли способа смешивать в одном csproj'е код шарпа и код MC++
csproj -- это c# project file. Конечно, он не может содержать код на MC++.
Re[2]: Unmanaged и managed
От:
Аноним
Дата:
27.05.05 15:58
Оценка:
Здравствуйте, Mab, Вы писали:
А>>Для решения какой-нибудь задачи типа внедрения dll в адресное пространство чужого процесса или работа с хуками клавы\мыши куда приятнее пользоваться родным кодом, чем импортировать кучу функций. Mab>С трудом представляю, как для задачи внедрения можно применить managed code. Разве что внедрить загрузчик, поднять там хост и далее загружать сборку с managed кодом. Только вот зачем все это?
Я тоже с трудом представляю. Потому и спросил.
А>>Еще можно написать managed компоненту на MC++. Mab>Компоненту -- в смысле класс? Да можно. Подходящее по затратам решение, если API сложное и на C# через pinvoke тяжело получается.
Тяжело.
А>>А нет ли способа смешивать в одном csproj'е код шарпа и код MC++ Mab>csproj -- это c# project file. Конечно, он не может содержать код на MC++.
Хорошо, сформулируем по-другому. Как создать проект, компилируемый в единственный исполняемый файл, чтобы часть кода была на шарпе, а часть — на MC++ (с натив-апи-вставками)? Само собой, инфраструктура (обвязка) — managed.
А>Хорошо, сформулируем по-другому. Как создать проект, компилируемый в единственный исполняемый файл, чтобы часть кода была на шарпе, а часть — на MC++ (с натив-апи-вставками)? Само собой, инфраструктура (обвязка) — managed.
А откуда требование одного файла? Если проект достаточно большой, то в нем редко бывает всего одна сборка.
Вообще в одной сборке может быть несколько модулей (.netmodule), которые могли получаться в результате компиляции на разных языках -- и даже сделать ее средствами al можно. Но сама студия такого не поддерживает.
[]
А>Хорошо, сформулируем по-другому. Как создать проект, компилируемый в единственный исполняемый файл, чтобы часть кода была на шарпе, а часть — на MC++ (с натив-апи-вставками)? Само собой, инфраструктура (обвязка) — managed.
Смешанный код
В отличие от других CLR-языков MC++ позволяет легко смешивать управляемый и неуправляемый код....
Re[4]: Unmanaged и managed
От:
Аноним
Дата:
28.05.05 08:01
Оценка:
Здравствуйте, kig, Вы писали:
kig>Здравствуйте, Аноним, Вы писали:
kig>[]
А>>Хорошо, сформулируем по-другому. Как создать проект, компилируемый в единственный исполняемый файл, чтобы часть кода была на шарпе, а часть — на MC++ (с натив-апи-вставками)? Само собой, инфраструктура (обвязка) — managed.
kig>Это подойдет?
kig>Смешанный код
kig>В отличие от других CLR-языков MC++ позволяет легко смешивать управляемый и неуправляемый код....
Подойдет, если вы покажете, как добавлять туда шарп.
Re[4]: Unmanaged и managed
От:
Аноним
Дата:
28.05.05 08:04
Оценка:
Здравствуйте, Mab, Вы писали:
А>>Хорошо, сформулируем по-другому. Как создать проект, компилируемый в единственный исполняемый файл, чтобы часть кода была на шарпе, а часть — на MC++ (с натив-апи-вставками)? Само собой, инфраструктура (обвязка) — managed. Mab>А откуда требование одного файла? Если проект достаточно большой, то в нем редко бывает всего одна сборка.
Ну не фигачить же отдельный модуль только потому, что десяток API-функций надо вызвать. А импортировать их не хочется.
Mab>Вообще в одной сборке может быть несколько модулей (.netmodule), которые могли получаться в результате компиляции на разных языках -- и даже сделать ее средствами al можно. Но сама студия такого не поддерживает.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, kig, Вы писали:
kig>>Здравствуйте, Аноним, Вы писали:
kig>>[]
А>>>Хорошо, сформулируем по-другому. Как создать проект, компилируемый в единственный исполняемый файл, чтобы часть кода была на шарпе, а часть — на MC++ (с натив-апи-вставками)? Само собой, инфраструктура (обвязка) — managed.
kig>>Это подойдет?
А>Ну не фигачить же отдельный модуль только потому, что десяток API-функций надо вызвать. А импортировать их не хочется.
Не модуль, а сборку. Не вижу в этом решении ничего страшного -- чем он вам помешал?
Здравствуйте, <Аноним>, Вы писали:
А>А нет ли способа смешивать в одном csproj'е код шарпа и код MC++, чтобы __gc-классы предоставляли интерфейс для вызовов из шарпа с unmanaged-имплементацией (WinAPI)? Может, решение очевидно, но я не дотумкал?
Для этого совсем не нужно смешивать всё в одном проекте. Три проекта в одном солюшене — три сборки (две библиотеки и приложение C#).
Unmanaged C++ Library <-- Managed C++ Wrapper <-- C# Application.
Если этот способ подходит, то можно обратить внимание на бета версию C++/CLI там Managed C++ серьёзно переработан и выглядит гораздо приятнее. Ходят слухи о том, что в C++/CLI можно будет в одном проекте смешивать код на разных языках, но необходимости в этом не вижу...
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Re[2]: Unmanaged и managed
От:
Аноним
Дата:
31.05.05 05:14
Оценка:
Здравствуйте, LSL, Вы писали:
LSL>Если этот способ подходит, то можно обратить внимание на бета версию C++/CLI там Managed C++ серьёзно переработан и выглядит гораздо приятнее. Ходят слухи о том, что в C++/CLI можно будет в одном проекте смешивать код на разных языках, но необходимости в этом не вижу...
Да дело вот в чем. Все эти DllImport'ы глючат со страшной силой. Видимо, в маршалинге дело, хотя фиг его знает. Я взял пример с кодепроджекта, 1:1 его реализовал, добавил пропертигрид — и полезло: "External component throw an exception".
Следовательно, все это в анменеджд нужно. Кстати, враки все про поддержку старого кода и старых АПИ. Была бы хорошая поддержка — я бы и не заметил никаких проблем, как не замечаю их, программируя на плюсах.
Но: есть вещи, которые в анменедж не вытащить. Например, WndProc. Из анменеджд кода подписываемся на события, из менеджд их получаем.
При этом, разделять функциональность по 2-м проектам очень не хочется. Архитектура получается некрасивая. Идеальное решение — смешение в рамках одного проекта 2 языков, особенно если partial types.
Разумеется, проблема в нынешней скудности родной дотнетной функциональности и ее общей молодости. Были бы всякие WH_MOUSE_LL в System.Hooks, я б так не извращался.
Здравствуйте, <Аноним>, Вы писали:
А>Да дело вот в чем. Все эти DllImport'ы глючат со страшной силой. Видимо, в маршалинге дело, хотя фиг его знает. Я взял пример с кодепроджекта, 1:1 его реализовал, добавил пропертигрид — и полезло: "External component throw an exception".
Я предлагаю как раз без DllImport'ов. Лучше написать библиотеку-обёртку на C++/CLI.
А>Но: есть вещи, которые в анменедж не вытащить. Например, WndProc. Из анменеджд кода подписываемся на события, из менеджд их получаем.
В смысле в managed не вытащить? Так WndProc легко вытаскивается и все прочее... В DX SDK как раз так сделано..
А>При этом, разделять функциональность по 2-м проектам очень не хочется. Архитектура получается некрасивая. Идеальное решение — смешение в рамках одного проекта 2 языков, особенно если partial types.
Мне кажется наоборот, но я реальной задачи не знаю.
Если есть большая unmanaged библиотека, которую не хотелось бы переписывать на C#, то лучше создать промежуточную библиотеку-обёртку на C++/CLI. Получится, что оборачиваемую библиотеку можно будет использовать напрямую unmanaged приложениями без обёртки и managed приложениями через обёртку. Примерно так сделан Managed DirectX.
А>Разумеется, проблема в нынешней скудности родной дотнетной функциональности и ее общей молодости. Были бы всякие WH_MOUSE_LL в System.Hooks, я б так не извращался.
Если проект достаточно большой, то в нем редко бывает всего одна сборка.
