我在Windows 7 x64上运行32位.NET应用程序时出现问题，该应用程序似乎以第三方COM库为中心。这是设置：
我们的应用程序是为32位Windows XP编写的，但我们尝试进行设置，以便在64位Windows上正常运行。它依赖于P / Invoke和COM Interop以及几个32位第三方库。无法获取这些库的64位版本。
有问题的库是一个COM包装器，由供应商提供给他们的基于C的框架库（Windows XP以后不支持）。这个界面更容易使用.NET。但是，在64位Windows 7上，COM库在初始化期间似乎出现故障。该框架有一个名为Init（）的函数，该函数返回成功，但之后表现不正常。
该框架应该在初始化期间在注册表中查找配置信息（我们创建的自定义DLL的名称和其他元数据）。使用Sysinternals进程监视器我可以看到它在注册表的32位兼容性部分查询，但它似乎使用找不到它。
我可以通过与PowerShell（x86）中的COM接口交互来重现此行为，因此我认为我在Visual Studio中没有设置错误。
虽然这是踢球者。如果我在启用了托管过程的Visual Studio中在x64平台上运行我们的应用程序，它每次都可以运行。如果我禁用托管进程，或从Visual Studio外部运行，则每次都会失败。
有关允许此COM交互成功的托管环境的任何想法吗？
更新：应用程序肯定以32位模式运行。 Visual Studio配置为为x86构建它，我可以在任务管理器中看到* 32后面的名称。 Process Monitor还显示正在使用的WOW64 DLL。
答案 0 :(得分：1)
一个不同之处在于，visual studio托管过程并非静态地依赖于您的代码。因此它首先启动，.net加载并创建appdomain，然后加载.exe就像它是一个dll一样。
如果这是关键区别，那么您应该能够通过复制此方案在调试器之外运行应用程序。创建一个虚拟的.net exe，除了启动之外什么都不做，然后动态加载包含实际程序的dll。
这可能会让你更接近理解/解决问题，因为它排除了其他问题，并允许你从有效的东西出发。
答案 1 :(得分：1)
您无法将32位DLL加载到64位进程中（反之亦然）。如果你有一个使用DLL的应用程序包装并加载另一个DLL等，链中的所有DLL必须是64位才能加载。如果其中一个DLL是32位，它们将无法加载，您的应用可能会失败。
因为您依赖于这些32位DLL，所以将所有EXE标记为仅32位可能是最明智的。您可以将自己的DLL保留为支持32位或64位，但是通过将EXE限制为仅32位，您也可以将所有加载的资源强制为32位。
您将应用移植到64位是否有特定原因？