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

Question

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

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

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

Имеет ли смысл скомпилировать весь мой код C ++ с опцией /CLR? Это сработает?

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

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

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

Просто заявите: с чего начать?

Патрик

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

Мы также можем размещать .net usercontrols в существующем приложении C ++ (Winforms в любом случае - просто обертка вокруг Winapi, так что это работает довольно хорошо).

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