Мое приложение неуправляемо. Где я начинаю представлять управляемый код?
Мое целое приложение (который является довольно большим с исполняемым файлом 20 МБ) записано в неуправляемом C++. Поскольку я могу ясно видеть преимущества в использовании управляемого кода, я хочу начать представлять управляемый код в своем приложении, но где я запускаю?
Я могу легко начать использовать C++ / CLI и связывать его с остальной частью моего приложения? (хотя C++ / синтаксис CLI кажется довольно 'экзотичным').
Или лучше переместиться в C#, но что лучший способ состоит в том, чтобы 'связать' это вместе с моим неуправляемым кодом C++?
Имеет смысл компилировать весь мой код C++ с опцией сброса/? Это будет работать?
Я должен волноваться о маршалинге? Делает это дает издержки, или могу я переключаться между управляемым и неуправляемым без потери производительности (как я сделал 20 лет назад при смешивании Фортрана и C). Производительность действительно важна в моем приложении, так как это - научное приложение, которое иногда обрабатывает Несколько гигабайтов памяти.
Или только имеет смысл перепроектировать пользовательский интерфейс, и только писать это в C# и сохранять остальную часть моего приложения (логика вычисления, бизнес-логика, интерфейс БД...) в неуправляемом C++?
Так как мое приложение иногда должно обрабатывать Несколько гигабайтов памяти, у меня есть 64-разрядный вариант. Действительно ли легко иметь 64-разрядный управляемый код? Woudl сборщик "мусора" быть все еще эффективным, если так много памяти используется?
Просто состояние:с чего начать?
Patrick
3 ответа
На данный момент считайте этот вопрос закрытым.
Я понял, что ответ заключается не в смешивании C ++ и C #, а в том, чтобы в первую очередь получить правильную архитектуру.
Если архитектура правильная и отделена там, где она должна быть отделена, то изменение частей приложения другими модулями (внешними, на другом языке, ...) должно быть проще.
Что касается проблем с производительностью во время маршаллинга, нам придется подождать, пока .Net не станет более зрелым.
Профилируйте приложение, решите, в каких точках интеграции вы можете оторваться от логической линии C # и перейти на C ++ и наоборот. Объедините их в план, чтобы шаблон проектирования фасада перемещался по системе, постепенно заменяя C ++ на C #. Ключевым моментом для беспокойства является стоимость ЦП и памяти при принятии решения о переключении языков на каждом подходящем фасаде / интерфейсе.
Вы захотите иметь возможность вносить изменения, чтобы вам было лучше с одним набором исходного кода и репозиторием исходного кода для исходный код C ++ и другой набор и репозиторий для фасада плюс C #.
Затем, по мере того, как работы по усовершенствованию / обслуживанию поступают во входной лоток, вы применяете его к обеим кодовым базам, и вы пытаетесь убедиться, что фасад перемещается по системе, начиная с кода, который с наименьшей вероятностью изменится при улучшении или обслуживании, чтобы свести к минимуму дублирование работы по изменениям.
Также идеально структурируйте свою работу, чтобы вы могли откатить фасад, чтобы вернуться к 100 % C ++ без промедления, если вы наткнетесь на препятствие.
Чтобы проверить, можно ли разделить пару особенно непостижимых модулей C ++ на часть C ++ и часть C #, запустите их в двух разных процессах Win32 C ++, взаимодействующих с помощью труба или розетка. Таким образом, вы получите лучшее представление о том, есть ли проблемы с управлением памятью или производительностью, которые необходимо исправить, прежде чем вы сможете разделить цепочку вызовов на этом этапе.
Чтобы проверить, можно ли разделить пару особенно непостижимых модулей C ++ на часть C ++ и часть C #, запустите их в двух разных процессах Win32 C ++, взаимодействующих с помощью канала или сокета. Таким образом, вы получите лучшее представление о том, есть ли проблемы с управлением памятью или производительностью, которые необходимо исправить, прежде чем вы сможете разделить цепочку вызовов на этом этапе.
Чтобы проверить, можно ли разделить пару особенно непостижимых модулей C ++ на часть C ++ и часть C #, запустите их в двух разных процессах Win32 C ++, взаимодействующих с помощью конвейера или сокета. Таким образом, вы получите лучшее представление о том, есть ли проблемы с управлением памятью или производительностью, которые необходимо исправить, прежде чем вы сможете разделить цепочку вызовов на этом этапе.
Мы делаем именно то, что вы описали, в критически важном приложении, которое используют тысячи пользователей. По сути, мы сохранили существующее приложение как есть, поэтому исполняемый файл по-прежнему является на 100% неуправляемым исполняемым файлом (не C ++ / CLI). Затем мы помещаем весь наш новый код C # в DLL-файлы .NET, которые состоят из бизнес-объектов, пользовательских элементов управления, кода графического интерфейса и т. Д.
По сути, весь новый код написан на C #. У нас есть 1 dll, это C ++ / CLI, это просто клей. Это позволяет нам легко взаимодействовать между управляемым и неуправляемым кодом без необходимости делать существующий код C ++ clr. Это ограничивает объем кода C ++ / CLI, который мы должны написать. Собственный код взаимодействует с кодом смешанного режима, который может взаимодействовать с управляемым кодом. DLL смешанного режима может перехватывать события в классах C #, поэтому код C # может просто запускать событие для связи с C ++ / CLI (который может взаимодействовать с собственным кодом).
Мы также можем размещать .NET UserControls в существующем приложении C ++ (WinForms в любом случае является просто оболочкой для WINAPI, поэтому работает очень хорошо).
Это работает очень хорошо и позволяет сохранить существующий код без необходимости переписывать весь графический интерфейс на C #.