问题
We need to create a Shell Namespace Extension. I left windows programming in 2005, that time I had to create simple shell extensions, but built very complex COM servers (in-process and out-of-process) and desktops applications. We used ATL and MFC libraries.
The time has passed and now I need to come back to visual studio / windows programming. I was expecting to be able to forget all about ATL, MFC an C++, an create applications in de CLR with C#.
I remember it was really very difficult to find good ATL/MFC developers, and most of the times I had to do the whole work. So I imagine now, in the .NET age, it's going to be really impossible to find ATL/MFC developers that can help me.
And I've just seen this in the MSDN Library: http://msdn.microsoft.com/en-us/library/dd758089%28v=VS.85%29.aspx
"Microsoft recommends against writing managed Shell extensions and does not consider them a supported scenario." -
Oh no, no, no... I was excited and looking forward to using C#, WindowsForms, or even WPF, and they say I cannot.
So if I want to create a Windows unmanaged C++ application, are MFC/ATL the only options? Is it really true that in 6 years there haven't had any improvement. So I have to use the same old technologies?
I'm now looking for a better option in Visual Studio 2010, and it seems that for C++ unmanaged applications we still have to use MFC or ATL. My question is if this is really the only way.
And now we assume we have to use old MS libraries, and the Shell Extensions are all about COM interfaces, I think the better option is ATL.
But maybe we need to include some windows and some UI controls. I remember you can add MFC support to ATL projects or ATL support to MFC projects. I know I worked with that kind of things, but was ages ago. Can you please tell me what was the better options.
Thanks a Lot, from a Java lover and C++ nostalgic.
回答1:
There have been changes to MFC in the last 6 years, the feature pack is a big improvement. Changes to MFC (V9) and MFC V10 changes
Also ATL / MFC have been converging for a while and whilst I wouldn't be jumping up and down to recommend MFC over C#/WPF it's a lot better than it was in 2003.
If I was writing a shell extension today I'd be using ATL to start with and if I needed MFC I'd add MFC support to ATL
回答2:
While it's possible to create shell extensions in managed code, it's not a good idea because you can get into versioning problems if multiple extensions use different versions of the .NET framework. The reason is that shell extensions are loaded in-process, and a process can only load one version of the framework.
C++ with ATL would be my preferred choice, MFC second. You could also write it in C, but that's just a lot of work. You might be able to use Delphi (unmanaged) or some other languages as well.
回答3:
A note on logicnp's answer since I don't have rep to make comments...
Even if using .net 4.0 Microsoft recommends against using managed code: Microsoft recommends against writing managed in-process extensions to Windows Explorer or Windows Internet Explorer and does not consider them a supported scenario.
From: http://msdn.microsoft.com/en-us/library/dd758089%28v=VS.85%29.aspx.
Initially when .net 4.0 came out there I think there was a lot of confusion on this within Microsoft. The MSDN article logicnp links to in his answer -- does say you can use .net -- is an example of this.
You can still use .net to write out of process extensions for example preview handlers and (I think) Thumbnail handlers.
回答4:
Thanks a lot for all your answers, your are all very helpful people. I'd just like to tell what we are finally going to do, maybe it could inspire someone else.
We are going to implement the central process of our application as a C# executable application. This application will be in charge of all de logic, such as server communications, even Task Bar Icon notifications. That way we can build a very light extension dll, so we can minimize all the ATL code.
This solution just need a local communication between the extension dll and the main process. We are using COM technology in the extension DLL, so what wil be the point of using another communication technology?. We'll export an out-of-process COM API in the executable implemented with C#. And the extension DLL will use that COM objects to get all it need to show in the shell extension.
But we have a little problem.
I'm the only one that have knowledge and experience using ATL, the other windows developers in our teams are c# developers. And I cannot help then in this development, because I'm in charge of other piece of our system. We have to show results in very little time, and you know how difficult it is to learn ATL.
So we are going to build the extension in C# just for demonstrations, where we have a controlled environment. And then we'll migrate the extension from C# to C++.
Best Regards, Pedro Ballesteros
回答5:
There's a really nice series on the subject over at Code Project: The Complete Idiot's Guide to Writing Shell Extensions. It's got a few years already, but it's still relevant. I'd start there!
回答6:
See the following from our KB for EZNamespaceExtensions.Net, a product which makes it very easy to develop namespace extensions in .Net.
Namespace extensions may be loaded by arbitrary processes and before .Net runtime v4.0, managed code built against one version of the .Net runtime could not run in a process which has already loaded another version of the runtime.
The latest .Net 4.0/VS 2010 runtime fully supports in-process side-by-side loading of the .Net 4.0 runtime (and ALL future runtimes) with earlier .Net runtimes. See following excerpt from http://msdn.microsoft.com/en-us/magazine/ee819091.aspx "With the ability to have multiple runtimes in process with any other runtime, we can now offer general support for writing managed shell extensions-even those that run in-process with arbitrary applications on the machine."
Even if you develop your namespace extension using .Net 3.5 or earlier (VS 2008 or earlier), this is only a issue if your namespace extension will be distributed to the general public. This is not an issue at all if your namespace extension is going to be deployed internally within your company or in a similar controlled environment (as is often the case with namespace extensions). In this case since you know which versions of the .Net runtime are going to be installed on your company's computers you can use the corresponding tool for development. For example, if your company's computers will have .Net 2.0 runtime installed then you can safely develop your namespace extension with Visual Studio 2005. If your company's computers have only the .Net 1.0/1.1 runtime installed, then you should use VS 2002/VS 2003 or you can even use Visual Studio 2005 while targeting the 1.0/1.1 runtime when compiling (using MSBuild or various widely available setting files).
DISCLAIMER: I work for LogicNP Software, the developers of EZNamespaceExtensions.Net and EZNamespaceExtensionsMFC.
来源：https://stackoverflow.com/questions/8070367/shell-namespace-extension-c-c-mfc-at-what-to-use