Share via

Don't do Shell Extension Handlers in .NET

  • Article

If you are thinking about writing Shell extension handles in .Net, please think again.

https://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=125283&SiteID=1

(From Jesse Kaplan, one of the CLR Program Manager.)

"

Unfortunately unmanaged C++ is really the only way to go here.
Writing in-process shell extensions in managed code is actually a very dangerous thing to do because it has the effect of injecting your managed code (and the .NET Framework) into every application on the machine that has a file open dialog.
The problems occur because only one version of the .NET Framework can be loaded in a process at any given time (other shared components such as java and msxml have the same property and thus the same restriction).
If you write your shell extension using the 2.0 .NET Framework and an application built with the 1.1 .NET Framework uses a file open dialog, your shell extension will fail because it can not run on an earlier version. Things can get even worse if your shell-extension manages to get loaded in a process before another applications managed code does: your extension may force an existing application onto a different runtime version than the one it was expecting and cause it to fail.
Because of these problems we strongly recomend against using any single-instance-per-process runtime or library (such as the .NET Framework, java, or msxml) in an in-process shell extension.

"

Comments

  • Anonymous
    December 02, 2005
    Thank you Junfeng,

    this is very interesting. Does this problem apply to COM Addins, too? I wrote a lot of COM Addins (for Microsoft Project and Outlook).
    Some of them are managed, some unmanaged. Should I worry that the managed dlls will have problems with future versions of .Net (as I can't control other Addins the user might have installed I can't control the framework version) ? What if I plan to upgrade the Addins to 2.0 myself? Will any 1.1 Addin that could get loaded before break my addin?

    Thank you in advance

  • Anonymous
    December 02, 2005
    The lastest CLR will be loaded for COM addins. So if you believe CLR's compatibility story you should be covered.

    The shell extension is a little different, because it is bleed to other applications (like the file open dialog example above). If the COM addin does not bleed to other processes, it should be fine.

  • Anonymous
    December 04, 2005
    Good to hear so our Addins will work for quite some time hopefully. Is it to be expected that 1.1 programs will still work in a .Net 3.0 / 4.0 runtime? I know this might be difficult to answer but your "believing the compatibility story" sounded a little skeptical...

  • Anonymous
    December 09, 2005
    I will expect v1.1 applications will work on any future version of .Net, as far as CLR is concern.

    But I can't guarantee anything on the libraries you depend on.

  • Anonymous
    January 31, 2006
    Recently I was developing a little one-off application for use on our home computer that I share with...

  • Anonymous
    November 11, 2006
    PingBack from http://www.mastropaolo.com/2006/11/08/shell-extensions-in-c-andor-vbnet/

  • Anonymous
    February 26, 2008
    PingBack from http://www.damonpayne.com/PermaLink,guid,dd549bd6-6933-4113-a253-41c58f78c1e8.aspx

  • Anonymous
    January 17, 2009
    PingBack from http://www.hilpers.com/1180734-probleme-mit-vc2008-clr

  • Anonymous
    January 18, 2009
    PingBack from http://www.keyongtech.com/729364-context-and-property-shell-extensions

  • Anonymous
    January 20, 2009
    PingBack from http://www.hilpers.com/303025-wie-kann-man-im-windows

  • Anonymous
    January 21, 2009
    PingBack from http://www.keyongtech.com/432355-creating-shell-extensions-in-c