我遇到与this question相关的问题。两名球员：
该应用程序必须支持从Windows XP（32位）到Windows 7（32位和64位）的任何内容。组件以不同方式复杂化。它包含托管的C ++ / CLI代码和一些与本机DirectX共舞的本机C ++类。它还链接到一些32位本机dll的w / o源访问（包含带导入库的C ++类）。
在32位环境（XP和7测试版）中运行良好，包括Windows 7上的32位子系统。只要在64位系统上使用“任何CPU”来构建完整的解决方案，就会发生浩劫。 32位组件不可用 - 但似乎只在调试模式下（“无法加载，格式错误”等）。 似乎在发布中工作。通过对所提到的32位第三方dll的隐式依赖性来防止64位汇编构建。
有没有办法提供能够使用程序集的真正原生64位应用程序？
装配的要求并不严格。它可能是 - 32或64位 - 但如上所述，应该可以从应用程序中以这种方式使用。
答案 0 :(得分：4)
在64位版本的Windows中，您遇到了严重的限制，64位进程无法在进程中执行任何32位机器代码。当您使用C ++ / CLI并使用DirectX时，您肯定依赖于机器代码。虽然听起来不像是无法在64位模式下执行，但C ++ / CLI和DirectX都可以编译/以64位格式提供。
然后归结为构建和部署问题。您 以64位模式构建C ++ / CLI项目，并在64位操作系统上部署仅 64位组件。必须为AnyCPU构建主EXE。同样，在32位操作系统上，您必须仅构建和部署32位编译版本。您可以通过将x64配置添加到解决方案来解决构建问题，以便分别构建32位和64位版本。您可以通过创建两个安装程序来解决部署问题。
由于您无论如何都必须支持32位操作系统，因此简单的解决方案是将 EXE项目上的目标平台设置更改为x86。现在一切都始终以32位模式运行，您不必担心构建和部署问题。您唯一错过的是64位版本中可用的较大虚拟内存地址空间。
答案 1 :(得分：0)
暂时忘掉C ++ / CLI项目。
您有第三方32位DLL。这些无法在64位进程中加载。所以你的主要应用程序必须是32位。此限制与C ++ / CLI中间人无关。
从64位应用程序中使用这些DLL的唯一方法是在单独的（32位）进程中加载它们并来回编组数据。