ATL OR C# for windows shell/namespace extenssion?

Question

Hi, i have a question, after allot of hours in googling and reading articles, i understood that namespace extenssion in windows is quite tricky (In C++ at least), now i've also seen its possible to do so in C# , but microsft does'nt officaly confirms using .net for namespace extensions... though i have seen very nice commercial Namespace Extenssion framework , but none is free....

so to my question :) , i want to develop my own Namespace Extenssion ,i have C++/C# knwoledge and basic COM/ATL , but if it can be done i prefer c#, so does c# inteop can fully do the work without too many tricks ? or one shall go diving in the ATL to create the neccessary COM objects...

thanks!

Answer 1

In general, up 'til now, it's been a bad idea to write a shell extension in managed code. A process only loads one version of the CLR and if someone else picked a different version first, bang, you're dead.

This may be changing in the near future, but at this point stick with native code for your shell extension.

Answer 2

EDIT: Here's some official words on the subject:

http://msdn.microsoft.com/en-us/magazine/ee819091.aspx

Note the very precise information about how code targeting 2.x and later can coexist with 4.0 inside the same process. So although SxS is a 4.0 feature, it has benefits for 2.x users.

However, there is this stipulation:

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. We still do not support writing shell extensions using any version earlier than .NET Framework 4 because those versions of the runtime do not load in-process with one another and will cause failures in many cases.

So there's an extra problem: the explorer.exe process isn't the only process that hosts shell extensions. Any program that has the File Open dialog may need to load shell extensions. So your .NET 2.0-3.5 extensions would fail to load within any .NET 1.x application's File Open dialog. It's going to be a similar story with things like the GUI components of printer drivers, which also load into any application that shows the standard Printer dialog.

Therefore, if you want to develop a managed shell extension, VS2010 is the place to start.