views:

163

answers:

3

The recommendation used to be "Do not write in-process shell extensions in managed code."

But with .NET Framework 4 and In-Process Side-by-Side the main reason not to write shell extensions in managed code should be resolved.

With that said, I have three questions.

  1. Is it now okay to write shell extensions in managed code?
  2. Which problems, if any might there be with writing shell extensions in managed code?
  3. What reasons might there be to write shell extensions in unmanaged code?
+1  A: 

It is now OK to write shell extensions in .NET 4 managed code. You should still avoid writing shell extensions in .NET 3.5 or earlier, because these earlier versions don't support in-proc side-by-side with each other.

Daniel Plaisted
Thanks for the answer, I guess I will have to try and write one and do some tests.
Jens Granlund
+1  A: 
  1. Yes, its OK.
  2. A huge problem and time-hogger is the large amount of shell interface, functions, structures, etc that you have to declare in managed code. You have to be very careful as even a single incorrect declaration of a single parameter can cause blowups, access violations, memory leaks and what not that can require hours to track down.
  3. The only reason is if you prefer or a forced to use an unmanaged language.

Check out EZNamespaceExtensions.Net which eliminates #2 above as well as the time required to develop namespace extensions in general (whether in managed or unmanaged).

logicnp
Thanks, I have written shell extensions in c++ and the shell api is not that straightforward so I guess it´s the same if you use it from c#. I found this, Managed Mini Shell Extension Framework - http://mmsf.codeplex.com/ but I haven´t looked in to it yet.
Jens Granlund
+2  A: 

Check out this MSDN article: Writing Windows Shell Extension with .NET Framework 4 (C#, VB.NET) - Part 1 http://blogs.msdn.com/b/codefx/archive/2010/09/14/writing-windows-shell-extension-with-net-framework-4-c-vb-net-part-1.aspx

dude
Thanks, It looks promising.
Jens Granlund