none
Shell extensions in .net

    Question

  • Hello,

    As far as I know it is not recommended to develop shell extensions (context menu) as it is not possible to load several versions of clr. As clr 4.0 makes it possible to load multiple versions, is it still discouraged to develop them in .Net? If yes, then what is the recommended way of developing application in .Net that needs to add entries to windows context menu?

    Thank you.
    MCTS, CodeProject MVP 2008
    Monday, September 21, 2009 6:04 PM

Answers

  • Giorgi,

    I should apologize.  After further investigation, it looks like Managed Shell Extensions are going to be supported in .NET 4.

    The CLR Team blogged about SxS in .NET 4 .  In the comments of the linked post, Aarthi reponded to David:

    David, That is correct - now that multiple CLRs can be hosted in one process at once, it is possible to write managed shell extensions. We will be writing a post exclusively covering this aspect very soon. Aarthi

    However, the follow up post hasn't been made - but it does look like Managed Shell Extensions will be possible with .NET 4.

    -Reed

    Reed Copsey, Jr. - http://reedcopsey.com
    Monday, September 21, 2009 6:51 PM
  • Confirmed, the in-process side-by-side support for multiple CLR versions was specifically targeted to solve this problem.  That still doesn't make shell programming any easier, the COM interfaces are tuff to deal with.  I haven't seen a sign of any wrappers yet.
    Hans Passant.
    Monday, September 21, 2009 10:06 PM

All replies

  • I'd still follow Jesse Kaplan's advice mentioned on Junfeng Zhang's blog :

    Unfortunately unmanaged C++ is really the only way to go here.

    VS2010 and CLR 4.0 provide a way to target and compile on multiple versions of the CLR, and change some of this behavior, but it still doesn't change the fact that a 1.1 application opening a file dialog will try to load a 2.0+ version of the CLR.  It's not just .NET that's a problem here, that same reference states:

    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.

    In general, shell extensions should be written in native C++.
    Reed Copsey, Jr. - http://reedcopsey.com
    Monday, September 21, 2009 6:14 PM
  • Thank you for your reply.

    According to the blog post you linked to:

    The problems occur because only one version of the .NET Framework can be loaded in a process at any given time


    But Clr 4.0 supports using multiple .Net versions in one process so logically the problem should be gone. Am I mistaken?

    Thank you.

    MCTS, CodeProject MVP 2008
    Monday, September 21, 2009 6:31 PM
  • its one of those just because you can doens't mean you should things, getting multiple clr's loaded in 4.0 does indeed take away one of the issues with it, on the other side there's still the problem of the massive memory usage (30mb+ is not uncommon for a failry basic clr app) and the increased cold start times, rightclicking something and having to wait 5-10 seconds even if its only once would still infuriate alot of your users.

    Monday, September 21, 2009 6:44 PM
  • Giorgi,

    I should apologize.  After further investigation, it looks like Managed Shell Extensions are going to be supported in .NET 4.

    The CLR Team blogged about SxS in .NET 4 .  In the comments of the linked post, Aarthi reponded to David:

    David, That is correct - now that multiple CLRs can be hosted in one process at once, it is possible to write managed shell extensions. We will be writing a post exclusively covering this aspect very soon. Aarthi

    However, the follow up post hasn't been made - but it does look like Managed Shell Extensions will be possible with .NET 4.

    -Reed

    Reed Copsey, Jr. - http://reedcopsey.com
    Monday, September 21, 2009 6:51 PM
  • Confirmed, the in-process side-by-side support for multiple CLR versions was specifically targeted to solve this problem.  That still doesn't make shell programming any easier, the COM interfaces are tuff to deal with.  I haven't seen a sign of any wrappers yet.
    Hans Passant.
    Monday, September 21, 2009 10:06 PM
  • Hi,

    At Tech Ed 2009 in New Zealand we were specifically told by one of the speakers (sorry, forgot which one) that creating shell extensions, browser plug-ins etc. was now allowed/advised with .Net 4.0 as it solved the multiple-simulataneously loaded framework issue. In fact, the speaker alluded to the fact they had to do this because they realy wanted to let people write office plug-ins, and they had exactly the same problem there.

    However, like I said, I can't remember the speakers name and I have no idea how trustworthy his advice is... only that he said Microsoft was dropping the advice not to use .Net for these types of development (from version 4 onward).

    Monday, September 21, 2009 11:18 PM
  • Hey

    I received an followup today. the Microsoft All-In-One Code Framework team is working on a series of .NET 4 shell extension code samples. They have released their context menu handler sample: CSShellExtContextMenuHandler, VBShellExtContextMenuHandler. Check out this thread for more details: http://social.msdn.microsoft.com/Forums/en-US/clr/thread/7ceb44d5-dce8-4197-ac55-f0f4fb59eeb4.

    • Proposed as answer by Dev.eloper Wednesday, September 22, 2010 3:01 PM
    Wednesday, September 15, 2010 6:36 AM
  • Seriously?

    Have you tried it?  We have a full namespace extension written that is quite spiffy.  It just has to architected better.  If all the visual elements are done in managed code and the actual business processing is done in a seperate process everything works nicely including hooking callback into managed code from a Filter Driver all working happily inside of the explorer process.

    Thursday, February 24, 2011 7:57 PM