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

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

時間已過，現在我需要回到視覺工作室/ windows編程。我希望能夠忘記所有關於ATL，MFC和C++的知識，用C＃在CLR中創建應用程序。

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

而且我剛看到這個MSDN Library中： http://msdn.microsoft.com/en-us/library/dd758089%28v=VS.85%29.aspx

「微軟建議不要編寫託管外殼擴展，不考慮他們支持的方案」 -

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

因此，如果我想創建一個Windows非託管C++應用程序，唯一的選擇是MFC/ATL？ 6年來的確沒有任何改善，這是真的嗎？所以我必須使用相同的舊技術？

我現在在Visual Studio 2010中尋找一個更好的選項，看起來對於C++非託管應用程序，我們仍然需要使用MFC或ATL。我的問題是如果這真的是唯一的方法。

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

但也許我們需要包括一些窗口和一些用戶界面控件。我記得你可以將MFC支持添加到ATL項目或對MFC項目的ATL支持。我知道我從事這種事情，但很久以前。你能告訴我什麼是更好的選擇。

非常感謝，來自Java愛好者的和C++的懷舊感。

來源

2011-11-09 Pedro Ballesteros

正如您已經發現的那樣，Microsoft在.NET中不支持在.NET中執行外殼擴展。我會用ATL去...... –

@ K-ballo：在外殼擴展中使用CLR不僅僅是不被支持，而且也是潛在的危險，因爲它可能會將CLR注入到其他使用公共文件對話框的毫無疑問的應用程序中。 –

@JörgenSigvardsson：包括運行在不同版本的.Net上的其他.Net應用程序......以BOOM結尾 – Brook

MFC在過去的6年裏發生了變化，feature pack是一個很大的改進。 Changes to MFC (V9)和MFC V10 changes

也ATL/MFC已經收斂了一段時間，雖然我不會在C＃/ WPF上推薦MFC，但它比2003年好多了。

如果我在寫一個shell擴展今天我會使用ATL開始，如果我需要MFC我最好add MFC support to ATL

來源

2011-11-09 20:25:56

非常感謝您的建議。我一直在想，使用ATL項目並在需要的情況下添加MFC支持。但很高興看到其他意見，這有助於加強決策。 –

在Code Project上有關於這個主題的非常好的系列：The Complete Idiot's Guide to Writing Shell Extensions。它已經有幾年了，但它仍然相關。我會從那裏開始！

來源

2011-11-09 19:53:08

這些不是* Shell **命名空間**擴展*，但是那裏有一些好的同樣的作者也相信這一點。 –

雖然可以在託管代碼中創建外殼擴展，但這不是一個好主意，因爲如果多個擴展使用不同版本的.NET框架，則可能會出現版本控制問題。原因在於shell擴展在進程中加載，並且進程只能加載一個版本的框架。

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

來源

2011-11-09 20:07:18

-1

見我們KB以下的EZNamespaceExtensions.Net，一個產品，使得它很容易在.Net中開發命名空間擴展。

命名空間擴展名可能被任意進程加載，並且在.Net runtime v4.0之前，針對一個.Net運行時版本創建的託管代碼無法在已加載另一版本運行時的進程中運行。

最新的.Net 4.0/VS 2010運行時完全支持.Net 4.0運行時（以及所有未來運行時）的進程內並行加載與早期的.Net運行時。「由於能夠在任何其他運行時處理多個運行時，我們現在可以提供對編寫託管shell擴展的一般支持 - 即使是那些在機器上隨意運行的應用程序。」

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

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

來源

2011-11-11 03:57:25 logicnp

[實施進程內擴展指導]（http://msdn.microsoft.com/zh-cn/library/dd758089%28v=VS.85%29.aspx）「** Microsoft建議不要編寫託管進程擴展到Windows資源管理器或Windows Internet Explorer，並不認爲它們是受支持的場景。**「 –

非常感謝所有的答案，你們都是非常有幫助的人。我只想告訴我們最終會做什麼，也許它可以激發別人。

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

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

但是我們有一點問題。

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

因此，我們將在C＃中構建擴展，僅用於演示，我們擁有受控環境。然後我們將C＃的擴展遷移到C++。

最好的問候，佩德羅巴列斯特羅斯

來源

2011-11-11 09:34:45

有關如何爲您實現的任何評論？我正在開始做同樣的事情：儘可能多地在C＃中放置代碼，儘可能少地寫入C++/ATL/COM，以滿足explorer.exe的需求。 –

了一份關於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出現時，我認爲在Microsoft內部存在很多混淆。 MSDN文章的logicnp鏈接到他的答案 - 確實說你可以使用.net - 就是這樣一個例子。

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

來源

2013-07-22 17:47:46 Wes

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

回答

相關問題