Не нужно много "преобразований", вы можете просто включить / clr и скомпилировать. Там будут ошибки сборки, но не огромное количество.
Это решение, которое не следует воспринимать легкомысленно. Когда вы пересекаете порог / clr, вы жертвуете несколькими вещами:
Производительность сборки значительно ухудшается, особенно при связывании. Вы не можете постепенно ссылаться на проект C ++ / clr.
Дополнительный загрузочный слой добавлен в ваши .Exe или .Dll. Вы должны быть осторожны с порядком инициализации, особенно со статикой. Это стало намного лучше, начиная с VS2005, но все еще есть икоты. У меня есть проект DLL / clr, который не выгружается правильно, и я не смог понять, почему. Одним из симптомов таких проблем является то, что вы не получаете выход дамона обнаружения утечки памяти из отладки.
Когда вы добавляете функциональность в проект, вы можете выбрать управляемую или собственную реализацию. Если вы решите перейти на что-то, что делается в другом месте проекта, вам нужно будет выбрать, пересмотреть ли более старую реализацию?
Пересечение управляемого собственного порога влияет на производительность и отладку.
Обработка исключений становится более сложной.
Вместо того, чтобы переключать ключ / clr на весь проект, я рекомендую более целенаправленный подход. Держите свою большую библиотеку родной. Создайте смешанный режим / clr bootstrapper / wrapper. Этот «тонкий прокси» обеспечивает преимущество доступа к вашей нативной библиотеке, сохраняя стабильность и производительность нативной библиотеки.
Если у вас есть диалоговые окна (или, что еще хуже, представления SDI / MDI, см. здесь ) в вашей собственной библиотеке, может быть сложно подключить дисплей. Но оно того стоит.