Shell命名空間擴展。 C＃。 C ++，MFC，AT-用什么？

Question

我們需要創建一個Shell命名空間擴展。 我在2005年離開了Windows編程，那時我不得不創建簡單的shell擴展，但是構建了非常復雜的COM服務器（進程內和進程外）和桌面應用程序。 我們使用ATL和MFC庫。

時間已經過去了，現在我需要回到visual studio / windows編程。 我期待能夠忘記所有關於ATL，MFC和C ++，使用C＃在de CLR中創建應用程序。

我記得找到優秀的ATL / MFC開發人員確實非常困難，而且大部分時間我都要完成整個工作。 所以我現在想象一下，在.NET時代，找到可以幫助我的ATL / MFC開發人員真的是不可能的。

我剛剛在MSDN Library中看到過： http ： //msdn.microsoft.com/en-us/library/dd758089%28v=VS.85%29.aspx

“Microsoft建議不要編寫托管的Shell擴展，並且不認為它們是受支持的方案。” -

哦不，不，不...我很興奮並期待使用C＃，WindowsForms甚至WPF，他們說我做不到。

那么如果我想創建一個Windows非托管C ++應用程序，MFC / ATL是唯一的選擇嗎？ 在6年內沒有任何改進是真的嗎？ 所以我必須使用相同的舊技術？

我現在正在尋找Visual Studio 2010中更好的選項，似乎對於C ++非托管應用程序，我們仍然必須使用MFC或ATL。 我的問題是，這是否真的是唯一的方法。

現在我們假設我們必須使用舊的MS庫，Shell Extensions都是關於COM接口的，我認為更好的選擇是ATL。

但也許我們需要包含一些窗口和一些UI控件。 我記得你可以為ATL項目添加MFC支持或者為MFC項目提供ATL支持。 我知道我曾經使用過那種東西，但很久以前。 你能告訴我什么是更好的選擇。

非常感謝Java愛好者和C ++懷舊。

Answer 1

關於logicnp答案的說明，因為我沒有代表發表評論......

即使使用.net 4.0，Microsoft建議不要使用托管代碼： Microsoft建議不要將托管進程內擴展寫入Windows資源管理器或Windows Internet Explorer，並且不認為它們是受支持的方案。

來自： http ： //msdn.microsoft.com/en-us/library/dd758089%28v=VS.85%29.aspx 。

最初當.net 4.0出現在那里時，我認為微軟內部存在很多混淆。 MSDN文章logicnp在他的回答中鏈接 - 確實說你可以使用.net - 就是一個例子。

您仍然可以使用.net來編寫進程擴展，例如預覽處理程序和（我認為）縮略圖處理程序。

Answer 2

雖然可以在托管代碼中創建shell擴展，但這不是一個好主意，因為如果多個擴展使用不同版本的.NET框架，您可能會遇到版本問題。 原因是shell擴展是在進程中加載​​的，而進程只能加載一個版本的框架。

帶有ATL的C ++將是我的首選，MFC第二。 你也可以用C語言編寫它，但這只是很多工作。 您也許可以使用Delphi（非托管）或其他語言。

Answer 3

在過去的6年中，MFC已經發生了變化， 功能包是一個很大的改進。 對MFC（V9）和MFC V10的更改發生了變化

此外ATL / MFC已經融合了一段時間，雖然我不會上下推薦MFC而不是C＃/ WPF，它比2003年要好很多。

如果我今天正在編寫shell擴展，我將使用ATL開始，如果我需要MFC，我會向ATL添加MFC支持

Answer 4

非常感謝你的所有答案，你們都非常樂於助人。 我想告訴我們最終要做什么，也許它可以激勵別人。

我們將作為C＃可執行應用程序實現應用程序的中央過程。 該應用程序將負責所有de邏輯，例如服務器通信，甚至任務欄圖標通知。 這樣我們可以構建一個非常輕的擴展dll，因此我們可以最小化所有ATL代碼。

該解決方案只需要擴展dll和主進程之間的本地通信。 我們在擴展DLL中使用COM技術，那么使用其他通信技術有什么意義呢？ 我們將在使用C＃實現的可執行文件中導出進程外COM API。 並且擴展DLL將使用該COM對象來獲取它在shell擴展中顯示的所有內容。

但我們有一點問題。

我是唯一一個擁有使用ATL知識和經驗的人，我們團隊中的其他Windows開發人員都是c＃開發人員。 在這個開發中我無法幫助，因為我負責我們系統的其他部分。 我們必須在很短的時間內顯示結果，你知道學習ATL是多么困難。

所以我們將在C＃中構建擴展，僅用於演示，我們有一個受控環境。 然后我們將擴展從C＃遷移到C ++。

最誠摯的問候，Pedro Ballesteros

Answer 5

Code Project上有一個關於這個主題的非常好的系列： 完整的白痴編寫Shell擴展指南 。 它已經有幾年了，但它仍然具有相關性。 我從那里開始！

Answer 6

請參閱我們的KB for EZNamespaceExtensions.Net中的以下內容 ，該產品可以非常輕松地在.Net中開發名稱空間擴展。

命名空間擴展可以由任意進程加載，在.Net運行時v4.0之前，針對.Net運行時的一個版本構建的托管代碼無法在已加載另一版本的運行時的進程中運行。

最新的.Net 4.0 / VS 2010運行時完全支持.Net 4.0運行時（以及所有未來運行時）與早期.Net運行時的進程內並行加載。 請參閱以下摘錄自http://msdn.microsoft.com/en-us/magazine/ee819091.aspx “由於能夠在任何其他運行時使用多個運行時，我們現在可以為編寫托管shell擴展提供一般支持 -甚至那些在機器上運行任意應用程序的進程。“

即使您使用.Net 3.5或更早版本（VS 2008或更早版本）開發名稱空間擴展，如果您的名稱空間擴展將分發給普通公眾，這只是一個問題。 如果您的命名空間擴展將在公司內部或類似的受控環境中部署（通常是命名空間擴展的情況），那么這根本不是問題。 在這種情況下，由於您知道將在公司的計算機上安裝.Net運行時的哪個版本，因此您可以使用相應的工具進行開發。 例如，如果您公司的計算機安裝了.Net 2.0運行時，那么您可以使用Visual Studio 2005安全地開發命名空間擴展。如果您公司的計算機只安裝了.Net 1.0 / 1.1運行時，那么您應該使用VS 2002 / VS在編譯時（使用MSBuild或各種廣泛使用的設置文件），您甚至可以在使用Visual Studio 2005時瞄准1.0 / 1.1運行時。

免責聲明：我為LogicNP Software工作，他是EZNamespaceExtensions.Net和EZNamespaceExtensionsMFC的開發人員。