COM互操作可能受Visual Studio宿主进程影响吗？
我在Windows 7 x64上运行32位.NET应用程序时出现问题，这似乎以第三方COM库为中心。这里的设置：COM互操作可能受Visual Studio宿主进程影响吗？
我们的应用程序是为32位Windows XP编写的，但我们试图设置，以便它可以在64位Windows上正常运行。它依赖于P/Invoke和COM Interop与几个32位第三方库。获得这些库的64位版本是不可能的。
有问题的库是由供应商提供给其基于C的框架库（不支持过去的Windows XP）的COM包装器。从.NET开始，这个接口要容易得多。但是，在64位Windows 7上，COM库在初始化期间似乎出现故障。该框架有一个名为Init（）的函数，它会以成功返回，但之后它不会“正常”运行。
该框架应该在初始化期间查找注册表中的配置信息（我们创建的自定义DLL的名称和其他元数据）。使用Sysinternals进程监视器我可以看到它在注册表的32位兼容性部分查询，但它似乎没有使用它发现。
我能够通过与来自PowerShell（x86）的COM接口进行交互来重现此行为，所以我不认为我在Visual Studio中有一个设置错误。
虽然这是踢球。如果我在启用了托管过程的情况下从Visual Studio运行我们的应用程序，则它每次都有效。如果我禁用托管进程或从Visual Studio外部运行，则每次都会失败。
任何想法是什么关于允许此COM交互成功的托管环境？
更新：应用程序肯定在32位模式下运行。 Visual Studio被配置为为x86构建它，并且我可以在任务管理器中看到* 32的名称。进程监视器还显示正在使用的WOW64 DLL。
一个区别是，视觉工作室托管过程不会静态地依赖于您的代码。所以它首先启动，.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位的特定原因？