问题
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.
- Is it now okay to write shell extensions in managed code?
- Which problems, if any might there be with writing shell extensions in managed code?
- What reasons might there be to write shell extensions in unmanaged code?
回答1:
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.
回答2:
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
回答3:
- Yes, its OK.
- 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.
- 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).
来源：https://stackoverflow.com/questions/2732475/in-proc-sxs-opens-for-shell-extension-in-managed-code