Question

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?
Was it helpful?

Solution

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.

OTHER TIPS

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

  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).

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top