.net COM互操作是否可能受到Visual Studio托管过程的影响？

我在Windows 7 x64上运行32位.NET应用程序时遇到问题，该应用程序似乎以第三方COM库为中心。以下是设置：

我们的应用程序是为32位WindowsXP编写的，但我们试图进行设置，使其能够在64位Windows上正常运行。它依赖于P/Invoke和COM互操作以及几个32位第三方库。无法获取这些库的64位版本

该库是一个COM包装器，由供应商提供给其基于C的框架库（过去的Windows XP不支持）。从.NET使用此接口要容易得多。但是，在64位Windows 7上，COM库在初始化期间似乎出现故障。该框架有一个名为Init（）的函数，该函数成功返回，但之后它的行为“不正常”

框架应该在初始化期间在注册表中查找配置信息（我们创建的自定义DLL的名称和其他元数据）。使用Sysinternals Process Monitor，我可以看到它在注册表的32位兼容性部分进行查询，但它似乎没有使用它找到的内容

我可以通过与PowerShell（x86）中的COM接口交互来重现此行为，因此我认为Visual Studio中的设置没有错误

这是踢球的人。如果我在VisualStudio的x64平台上运行我们的应用程序，并且启用了托管进程，那么它每次都可以工作。如果禁用宿主进程，或从Visual Studio外部运行，则每次都会失败

你知道什么是托管环境使这个COM交互能够成功吗

---

更新：应用程序肯定是在32位模式下运行的。VisualStudio配置为为为x86构建它，我可以在任务管理器中看到*32在其名称后面。Process Monitor还显示正在使用的WOW64 DLL。

一个区别是visual studio宿主进程并不静态地依赖于您的代码。所以它首先被启动，.net被加载，appdomain被创建，然后你的.exe被加载，就像它是一个dll一样

如果这是关键区别，那么您应该能够通过复制此场景在调试器之外运行应用程序。生成一个除了启动之外什么都不做的伪.net exe，然后动态加载包含实际程序的dll

---

这可能会使你更接近理解/解决问题，因为它排除了其他问题，并允许你从可行的事情开始

不能将32位DLL加载到64位进程中（反之亦然）。如果你有一个应用程序，它使用一个DLL包装并加载另一个DLL等，那么链中的所有DLL必须是64位才能加载。如果其中一个DLL是32位的，它们将不会加载，并且您的应用程序可能会失败

因为您依赖于这些32位DLL，所以最好将所有EXE标记为仅32位。您可以让自己的DLL支持32位或64位，但通过将EXE限制为仅32位，您将强制所有加载的资源也支持32位

您将应用程序移植到64位的具体原因是什么