COM互操作可能受Visual Studio宿主進程影響嗎？

Question

我在Windows 7 x64上運行32位.NET應用程序時出現問題，這似乎以第三方COM庫爲中心。這裏的設置：

我們的應用程序是爲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。

Answer 1

一個區別是，視覺工作室託管過程不會靜態地依賴於您的代碼。所以它首先啓動，.net被加載和appdomain被創建，然後你的.exe被加載，就好像它是一個dll。

如果這是關鍵區別，那麼您應該能夠通過複製此方案在調試器外部運行應用程序。製作一個虛擬的.net exe文件，除了啓動之外什麼也不做，然後動態加載一個包含實際程序的dll。

這可能會讓您更進一步瞭解/解決問題，因爲它排除了其他問題，並允許您從有效的方面着手。

Answer 2

無法將32位DLL加載到64位進程中（反之亦然）。如果您有一個應用程序使用封裝並加載另一個DLL的DLL，則鏈中的所有DLL必須爲64位才能加載。如果其中一個DLL是32位的，它們將不會加載，並且您的應用可能會失敗。

因爲你依賴於這些32位的DLL，所以將所有的EXE標記爲32位可能是最明智的。你可以留下你自己的DLL，以支持32位或64位，但是通過限制你的EXE僅爲32位，那麼你將強制所有加載的資源都變爲32位。

是否存在將應用程序移植到64位的特定原因？