C# - 混合汇编（C++/CLI、DirectX 本机）交互（32/64 位）
我有一个与此问题。两个参与者：
- C# 应用程序
- 1) 使用的混合程序集
应用程序必须支持从 Windows XP（32 位）到 Windows 7（32 和 64 位）的任何版本。组装过程在不同方面都很复杂。它包含托管 C++/CLI 代码和一些与本机 DirectX 配合的本机 C++ 类。它还链接到一些不带源访问权限的 32 位本机 dll（包含带导入库的 C++ 类）。
在 32 位环境（XP 和 7 测试）中运行良好，包括 Windows 7 上的 32 位子系统。一旦在 64 位系统上使用“任何 CPU”来构建完整的解决方案，就会发生严重破坏。 32 位程序集无法使用 - 但似乎仅在调试模式下（“无法加载，格式错误”等）。它似乎可以在发布中工作。对上述 32 位第三方 dll 的隐式依赖关系阻止了 64 位程序集构建。
有什么方法可以提供真正的本机 64 位应用程序来使用该程序集吗？
装配要求并不那么严格。它可以是 32 位或 64 位，但如上所述，应该可以通过应用程序以一种或另一种方式使用。
I have a problem related to this question. Two players:
- C# application
- Mixed assembly used by 1)
The application has to support anything from Windows XP (32bit) to Windows 7 (32 & 64bit). The assembly is complicated in different ways. It contains managed C++/CLI code and some native C++ classes dancing with native DirectX. It also is linked to a few 32bit native dll's w/o source access (containing C++ classes with import libraries).
Things are working well in 32bit environments (XP and 7 tested) including the 32bit subsystem on Windows 7. Havoc happens, as soon as "Any CPU" is used on 64bit systems in order to build the complete solution. The 32bit assembly is unusable than - but seemingly only in debug mode ("cannot load, wrong format" etc.). It seems to work in release. A 64bit assembly build is prevented by the implicit dependencies to the mentioned 32bit third-party dll's.
Is there any way to provide a real native 64bit application able to use the assembly?
Requirement for the assembly isn't that strict. It could be both - 32 or 64bit - but as said above, should be be usable from the application one way or the other.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您在 64 位版本的 Windows 中遇到了严格的限制，64 位进程无法在进程中执行任何 32 位机器代码。当您使用 C++/CLI 并使用 DirectX 时，您当然会依赖于机器代码。虽然听起来不像不能在 64 位模式下执行，但 C++/CLI 和 DirectX 都可以在 64 位模式下编译/可用。
这归结为构建和部署问题。您必须在 64 位模式下构建 C++/CLI 项目，并在 64 位操作系统上仅部署 64 位组件。主 EXE 必须针对 AnyCPU 构建。同样，在 32 位操作系统上，您必须仅构建和部署 32 位编译版本。您可以通过将 x64 配置添加到解决方案来解决构建问题，以便分别构建 32 位和 64 位版本。您可以通过创建两个安装程序来解决部署问题。
由于无论如何您都必须支持 32 位操作系统，因此简单的解决方案是将 EXE 项目上的目标平台设置更改为 x86。现在，一切都始终以 32 位模式运行，您不必为构建和部署问题而烦恼。您唯一错过的是 64 位版本中可用的更大虚拟内存地址空间。
You are running into a rock hard limitation in the 64-bit version of Windows, a 64-bit process cannot execute any 32-bit machine code in-process. You certainly have a dependency on machine code when you use C++/CLI and work with DirectX. Although it doesn't sound like you could not execute in 64-bit mode, both C++/CLI and DirectX can be compiled/are available in 64-bit.
This then boils down to a build and deployment issue. You have to build the C++/CLI project(s) in 64-bit mode and deploy only 64-bit components on a 64-bit operating system. The main EXE must be built to AnyCPU. Similarly, on a 32-bit operating system you must build and deploy only the 32-bit compiled version. You solve the build issue by adding the x64 configuration to the solution so you build the 32-bit and 64-bit version separately. You solve the deployment issue by creating two installers.
Since you have to support a 32-bit operating system anyway, the simple solution is to change the Target platform setting on your EXE project to x86. Now everything always runs in 32-bit mode and you don't have to bother with the build and deployment headaches. The only thing you miss out on is the larger virtual memory address space that's available in the 64-bit version.
暂时忘掉 C++/CLI 项目吧。
您有第三方 32 位 DLL。这些无法在 64 位进程中加载。因此您的主应用程序必须是 32 位的。此限制与 C++/CLI 中间人无关。
从 64 位应用程序使用这些 DLL 的唯一方法是将它们加载到单独的（32 位）进程中并来回编组数据。
Forget about the C++/CLI project for a minute.
You have third-party 32-bit DLLs. These CANNOT load in a 64-bit process. So your main application will have to be 32-bit. This restriction has nothing to do with the C++/CLI middleman.
The only way you can make use of these DLLs from a 64-bit application is to load them in a separate (32-bit) process and marshal data back and forth.