Мое приложение неуправляемое. Где я могу начать вводить управляемый код?

Question

Мое приложение (которое довольно большое, с исполняемым 20 МБ) написано на неуправляемом C++. Поскольку я могу ясно видеть преимущества использования управляемого кода, я хочу начать вводить управляемый код в своем приложении, но с чего начать?

Могу ли я начать использовать C++/CLI и связать его с остальной частью моего приложения? (хотя синтаксис C++/CLI кажется скорее «экзотическим»).

Или лучше перейти на C#, но как лучше всего «связать» это вместе с моим неуправляемым кодом на C++?

Имеет ли смысл скомпилировать весь мой код на C++ с параметром/clr? Будет ли это работать?

Должен ли я беспокоиться о сортировке? Это дает накладные расходы или я могу переключаться между управляемыми и неуправляемыми без штрафа за производительность (как и 20 лет назад при смешивании fortran и C). Производительность действительно важна в моем приложении, поскольку это научное приложение, которое иногда обрабатывает несколько гигабайт памяти.

Или имеет смысл переопределить пользовательский интерфейс и написать его только на C# и сохранить остальную часть моего приложения (логика вычисления, бизнес-логика, интерфейс базы данных, ...) в неуправляемом C++?

Поскольку для моего приложения иногда требуется обработка нескольких гигабайт памяти, у меня есть 64-битный вариант. Легко ли иметь 64-битный управляемый код? Woudl сборщик мусора будет по-прежнему эффективен, если эта память используется?

Просто укажите: с чего начать?

Patrick

Answer 1

На данный момент рассмотрите этот вопрос как закрытый.

Я понял, что ответ не смешивает C++ и C#, но в первую очередь получает архитектуру.

Если архитектура правильная и разделена там, где ее нужно разделить, то проще сменить части приложения другими модулями (внешними, другими языками, ...).

Что касается проблем с производительностью во время сортировки, нам придется подождать, пока .Net еще не созрел.

Answer 2

Профиль приложение, решить на то, что интеграция точек можно обрывать на C# линию логики и ворваться в C++ и наоборот. Расположите их в плане, чтобы шаблон дизайна фасада перемещался по системе, постепенно заменяя C++ на C#. Ключевой проблемой является стоимость процессора и памяти при принятии решения о переключении языков у каждого кандидата Facade/interface.

Вы хотите иметь возможность вносить изменения, поэтому вам может быть лучше с одним исходным кодом и репозиторием исходного кода для исходного кода C++ и другого набора и репозитория для фасада плюс C#.

Затем, когда усовершенствования/работы по техническому обслуживанию поступают в лоток, вы применяете его как к кодам баз, так и пытаетесь убедиться, что фасад перемещается по системе, начиная с кода, наименее вероятного изменения в усовершенствованиях или обслуживании, чтобы минимизировать удвоение изменений.

Также идеально структурируйте свою работу, чтобы вы могли откатить фасад, чтобы вернуться на 100% C++ при падении шляпы, если вы попали в ловушку.

Чтобы проверить, можно ли выделить несколько незащищенных модулей C++ в кусок C++ и часть C#, запустите их в двух разных процессах Win32 C++, обмениваясь данными с использованием канала или сокета. Таким образом, вы получите лучшее представление о том, есть ли проблемы с управлением памятью или производительностью, требующей исправления, прежде чем вы сможете разделить цепочку вызовов в этот момент.

Answer 3

Мы делаем именно то, что вы описали в критическом приложении, которое используется тысячами пользователей. В принципе, мы сохранили существующее приложение как есть, поэтому исполняемый файл по-прежнему является 100% неуправляемым исполняемым файлом (а не C++/CLI). Затем мы помещаем весь наш новый код C# в .NET dll, который состоит из бизнес-объектов, пользовательских элементов управления и gui-кода и т. Д ....

В принципе, все новые коды написаны на C#. У нас есть 1 dll, которая является C++/CLI, которая является просто клеем. Это позволяет нам легко взаимодействовать между управляемым и неуправляемым кодом, без необходимости делать существующий код C++ clr. Это ограничивает количество кода C++/CLI, который мы должны написать. Нативный код говорит о коде смешанного режима, который может разговаривать с управляемым кодом. DLL смешанного режима может перехватывать события на классах C#, поэтому код C# может просто запустить событие для связи с C++/CLI (который может разговаривать с собственным кодом).

Мы также можем размещать .NET UserControls в существующем приложении C++ (WinForms - это всего лишь оболочка WINAPI, так что это работает очень хорошо).

Это работает очень хорошо и позволяет сохранить существующий код без необходимости переписывать весь графический интерфейс на C#.