none
[C#] shell extension : IContextMenu.GetCommandString

    Question

  • i am looking into the SDK\v1.1\Technologies\Interop\Applications\ShellCmd which come with VS.Net 2003 (guess, me copy it somewhere from internet)

    the sample work well except the IContextMenu.GetCommandString,
    it should show the description on the Explorer statusbar, but it not.

    me have try to add MessageBox.Show() to check whether it have fired or not, and it fire when me rollover the menuitem.

    me running Windows XP SP2

    is there any idea to make it work?

    :: code copy from the sample ::
    void IContextMenu.GetCommandString(int idCmd, uint uFlags, int pwReserved, StringBuilder commandString, int cchMax) {
        switch(uFlags) {
            case (uint)GCS.VERB:
                commandString = new StringBuilder(m_items[idCmd - 1].command.Substring(1, cchMax - 1));
                break;
            case (uint)GCS.HELPTEXT:
                commandString = new StringBuilder(m_items[idCmd - 1].command.Substring(1, cchMax));
                break;
            case (uint)GCS.VALIDATE:
                break;
        }
    }

    Sunday, December 03, 2006 4:31 PM

Answers

  • 1: Probably, but if you're an extension or add-in, you're not in control of which runtime version gets loaded.

    2: You can configure Explorer to run as a single or as multiple processes. That doesn't really matter though. Each process loads its own version of the CLR. And separate copies of any shell extensions get loaded into each process.

    3: If you're in control of the machines the software it will run on, that may work. But in general you're just postponing the problem. The same issue will occur again when the next version of the CLR is released and you try to load any components compiled with that.

    5: I'm not sure this is something that can be fixed. It's an architectural decision made early in the design of the CLR.

     

    Monday, December 04, 2006 3:36 PM
    Moderator

All replies

  • I'm not sure I understand your problem. But before you spend more time writing shell extensions in C#; I recommend you read the following.

    http://blogs.msdn.com/junfeng/archive/2005/11/18/494572.aspx

     

    Sunday, December 03, 2006 7:05 PM
    Moderator
  • "The problems occur because only one version of the .NET Framework can be loaded in a process at any given time"
    1. me thought the framework are previous version compatibled?
    2. if only one framework can be loaded, that also mean me cant use difference version of .Net application at same time?like Paint.Net build with 1.1 and Note.Net build with 2.0, thay cannot run at same time?
    3. when we install .Net Framework 2.0, it will installed 1.1 as well?
    4. just wonder why this serious problem exist and the SDK still included the shell extensions sample?
    5. will .Net 3.0 fixed this problem?
    Monday, December 04, 2006 10:06 AM
  •  tlc660 wrote:

    1. me thought the framework are previous version compatibled?
    2. if only one framework can be loaded, that also mean me cant use difference version of .Net application at same time?like Paint.Net build with 1.1 and Note.Net build with 2.0, thay cannot run at same time?
    3. when we install .Net Framework 2.0, it will installed 1.1 as well?
    4. just wonder why this serious problem exist and the SDK still included the shell extensions sample?
    5. will .Net 3.0 fixed this problem?

    1: They mostly are, but they can't be forwards compatible. If Explorer happens to load the v1.0 CLR first, any extension that depends on v2.0 would fail to load.

    2: No, the restriction is just one version of the CLR per process. Different applications can use different versions.

    3: No

    4: Don't know, good question.

    5: No it doesn't.

     

    Monday, December 04, 2006 10:27 AM
    Moderator
    1. so, if me load the v2.0 first, then all v1.0/1.1 should be run well?
    2. me not understand well. you mean all shell extensions(which make with .net) will running in same process?
      but the COM plugin/standalone applications not?
    3. so, if me only install the v2.0, then no matter extensions make with v1.0 or v2.0 should all run well because there are backwards compatibled and only one version can be loaded
    4. 5. then thats really funny, because it havent fixed in 3.0 also, guess they might dont know this problem when v1.0 release
    Monday, December 04, 2006 12:23 PM
  • 1: Probably, but if you're an extension or add-in, you're not in control of which runtime version gets loaded.

    2: You can configure Explorer to run as a single or as multiple processes. That doesn't really matter though. Each process loads its own version of the CLR. And separate copies of any shell extensions get loaded into each process.

    3: If you're in control of the machines the software it will run on, that may work. But in general you're just postponing the problem. The same issue will occur again when the next version of the CLR is released and you try to load any components compiled with that.

    5: I'm not sure this is something that can be fixed. It's an architectural decision made early in the design of the CLR.

     

    Monday, December 04, 2006 3:36 PM
    Moderator
  • 2. you mean by modify the register setting [DesktopProcess]? when this options are on, so the problem will gone?

    3. yes, just postponing. but me guess there will not be a problem, because in future Vista are included the .Net 3.0 right? so there are no need v1/v2
    Tuesday, December 05, 2006 8:34 PM
  • 2: I mean the "Launch folder windows in a separate process" option you can set in Explorer's Folder Option dialog. That may correspond to the registry key you mentioned, I don't know. Bu no, that doesn't fix the problem.

    3: Until .NET 4.0 or whatever comes along.

     

    Wednesday, December 06, 2006 7:30 AM
    Moderator
  • 2. i see, then the only option are going to C++.
    3. hope it not come so soon

    me have an idea:
    if me create a COM with unmanaged c++ which just handle the shell extension command
    like IShellExtInit, IContextMenu
    and then pass the parameters receive to managed COM and let the managed COM to process, will it work?

    me dont know c++, but me saw an article that mention c++ and ATL and the ATL can auto generated the SimpleExt class, so it might help.
    Wednesday, December 06, 2006 11:34 AM
  • No that will not help.

     

    Monday, December 11, 2006 7:31 AM
    Moderator
  • Mattias Sjögren said:

    No that will not help.

     

    Can you elaborate this further?

    Lets say I create an unmanaged COM dll, which does the shell extension, and in InvokeCommand function I call my application written in C# using ShellExecute and pass to it selected file as an argument.

    Why is this not safe?
    Friday, July 11, 2008 12:44 PM
  • If you use ShellExecute(), you'll start another process.  There's no problem with another process loading the CLR, that cannot affect the version of the CLR loaded in the app that gets the shell extension loaded in its process space.  The entire problem has been getting easier to deal with as of late.  Every since .NET 2.0 came out, Microsoft has stopped producing side-by-side versions of the CLR.  Even the .NET 3.5 SP1 framework is using the old V2.0.50727 version number.  I assume this very problem has something to do with that.  That still produces versioning problems, just different ones. 
    Hans Passant.
    • Proposed as answer by Goran _ Tuesday, July 15, 2008 1:11 AM
    Friday, July 11, 2008 2:02 PM
    Moderator
  • Thanks.
    Tuesday, July 15, 2008 1:11 AM
  • Now .NET 4 has a working model for this?

     

    what would you replace StringBuilder commandString with in tlc660's code?

    Friday, June 17, 2011 9:02 PM