C # - смешанная сборка (C ++ / CLI, DirectX native) взаимодействие (32 / 64bit) - PullRequest
4 голосов
/ 31 марта 2011

У меня есть проблема, связанная с этим вопросом . Два игрока:

  1. C # приложение
  2. Смешанная сборка используется 1)

Приложение должно поддерживать все, от Windows XP (32-разрядная версия) до Windows 7 (32- и 64-разрядная версия). Сборка сложна по-разному. Он содержит управляемый код C ++ / CLI и некоторые собственные классы C ++, танцующие с собственным DirectX. Он также связан с несколькими 32-битными собственными dll без доступа к источникам (содержащими классы C ++ с библиотеками импорта).

Все хорошо работает в 32-битных средах (проверено XP и 7), включая 32-битную подсистему в Windows 7. Havoc происходит, как только «64-битный процессор» используется в 64-битных системах для построения полного решения. 32-битная сборка непригодна для использования, но, по-видимому, только в режиме отладки («невозможно загрузить, неверный формат» и т. Д.). Это кажется , чтобы работать в выпуске. Сборка 64-битной сборки предотвращается неявными зависимостями от упомянутых 32-битных сторонних библиотек DLL.

Есть ли способ предоставить настоящее собственное 64-битное приложение, способное использовать сборку?

Требования к сборке не так строги. Он может быть как 32-разрядным, так и 64-разрядным, но, как уже было сказано выше, его можно использовать из приложения тем или иным способом.

Ответы [ 2 ]

4 голосов
/ 31 марта 2011

Вы столкнулись с жестким ограничением в 64-разрядной версии Windows, 64-разрядный процесс не может выполнить ни один 32-разрядный машинный код в процессе. У вас наверняка есть зависимость от машинного кода, когда вы используете C ++ / CLI и работаете с DirectX. Хотя это не звучит так, как будто вы не можете выполнить в 64-битном режиме, C ++ / CLI и DirectX могут быть скомпилированы / доступны в 64-битном режиме.

Это сводится к проблеме сборки и развертывания. У вас есть для сборки проектов C ++ / CLI в 64-битном режиме и развертывания только 64-битных компонентов в 64-битной операционной системе. Основной EXE должен быть встроен в AnyCPU. Аналогично, в 32-разрядной операционной системе вы должны создавать и развертывать только 32-разрядную скомпилированную версию. Вы решаете проблему сборки, добавляя конфигурацию x64 в решение, чтобы создать 32-разрядную и 64-разрядную версии отдельно. Вы решаете проблему развертывания, создавая два установщика.

Поскольку в любом случае вам необходимо поддерживать 32-разрядную операционную систему, простое решение - изменить настройку целевой платформы в вашем EXE-проекте на x86. Теперь все всегда работает в 32-битном режиме, и вам не нужно беспокоиться о головной боли при сборке и развертывании. Единственное, чего вам не хватает, так это большего адресного пространства виртуальной памяти, доступного в 64-битной версии.

0 голосов
/ 03 апреля 2011

Забудьте на минуту о проекте C ++ / CLI.

У вас есть сторонние 32-битные библиотеки DLL.Они НЕ МОГУТ загружаться в 64-битном процессе.Таким образом, ваше основное приложение должно быть 32-разрядным.Это ограничение не имеет ничего общего с посредником в C ++ / CLI.

Единственный способ использовать эти библиотеки DLL из 64-разрядного приложения - это загрузить их в отдельный (32-разрядный) процесс и выполнить маршал.данные туда и обратно.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...