2010-02-05 26 views
0

我有一些C++代碼是一個管理單元的MMC基礎的應用。此管理單元通過COM包裝器(AssemblyA)使用.net 2.0 dll。 AssemblyA與啓動MMC會話的應用程序位於相同的目錄中。 AssemblyA使用一些其他的.NET的DLL(OtherAssemblies)的,我無法控制的原因不能住在同一目錄AssemblyA。它還允許動態加載一些組件(來自AssemblyB),並在第三個目錄中搜索這些組件。 AssemblyB中的動態組件引用AssemblyA,因爲它們在那裏擴展基類。爲什麼運行時不能自動解析我的程序集依賴項?

我的問題是,當我嘗試加載動態組件時,無法解析依賴到AssemblyA,並且我的AssemblyResolve處理程序被觸發(我正在使用它來解析OtherAssemblies)。當我查詢的AssemblyResolve處理Assembly.GetExecutingAssembly(),組裝我試圖解決的組裝。

這種行爲似乎有點怪我,因爲我本來期望的.NET運行時查找在加載的程序集的依賴關係,然後再局部大會我加載,然後在app目錄。其中的第一個和第三個應包含我試圖加載的程序集。

我已經修改了我的AssemblyResolve方法,以便它可以在其他位置搜索依賴關係,因此它可以工作,就像當前的應用程序目錄一樣,但如果我可以幫助它,我真的不想這樣做。

這種行爲是正常嗎?是由於它是一個MMC應用程序還是由於它是從C++調用的COM啓動的?我是笨蛋嗎?

回答

2

它既是。你運行MMC的事實使得.NET很難解析程序集,它不會在c:\ windows \ system32中找到任何東西。你無法用MMC的.config文件合理解決這個問題,它將會使用任何未來的插件。

COM也沒有幫助,放置COM DLL的目錄不會以任何方式影響探測路徑。你已經找到了解決這個問題的方法,AssemblyResolve。或者您可以將所有內容都放入GAC中。

或者你可以避免使用COM並直接用Microsoft.ManagementConsole namespace寫入MMC插件。

+0

virtual deja vous:http://stackoverflow.com/questions/2188024/c-calling-managed-com-object-cant-find-dependent-assemblies/2188116#2188116 – Ruddy 2010-02-05 13:34:30

+0

謝謝。我的擴展是一個現有插件的管理單元。不知道我是否可以重寫它來使用託管命名空間的現有C++插件,特別是它已經工作。 GAC並不是一個真正的選擇,所以它看起來像我現有的解決方案,但它感覺是錯誤的路要走。 – 2010-02-05 13:52:56

相關問題