I'm getting confused between IconHandler and IconOverlay aren't i. Handlers let you stop the caching, overlays don't. You get exactly one overlay per object any duplications being handled by the priority flag and call ordering. In order to get a different overlay you should just be able to return a different icon or offset into the icon resource assembly and it'll work. However be aware that the shell only allows a total of 16 overlay icons so if y ou've already got the system ones and the tortoise ones present you may well run out if you use any more.

in your IShellIconOverlayIdentifier.GetOverlayInfo method you need to return the path to the icon overlay and you should set the flags that prevent it being cached so that each call can return a different path and thus show a different icon. If you read the PSDK docs on the interface it tells you how to do this.

Consider: public abstract sealed class Tools { private Tools(){} } The static modifier in c#2.0 is implemented this way.

It depends which parts of the shell you want to extend, icon handlers and overlays are fairly simple while context menu extensions are rather more tricky. It all requires a reasonable amount of com and win32api interop and some fairly defensive programming to prevent errors reaching and crashing the shell if they occur. Some things like property sheets really aren't possible in fully managed code though that may change when the 2.0 CLR is released.

No.

Personally i define crashing as an error condition, and one of the bigger ones as well. I realize that HandleMenuMsg should be called but it should also not cause the hosting application to crash. If you look at the definitions of ContextMenu, 2 and 3 in ShlObj.h the methods are specified in a specific and exact order. When the runtime interop does its work it doesn't have a lookup table of method names, it puts the methods in the order they are in the class/interface. If you've got them in the wrong order they wrong method could be called. Put them in the right order and then go back and read through what is required for IContextMenu2 to run, perhaps a precondition isn't being met, perhaps a marshalling error is occuring before your function body is reached. Perhaps it is wrong in some way, but at least you'll know that the right method is being called with the right parameters at the right time if it ever is called.

But does it crash? Because not getting any messages may be the correct behavior while crashign certainly isn't.

Interesting, Mattias Sjögren is very knowledgable about these things. I've come across posts of his many times. The first thing that struck me was that the order of your methods doesn't match the example at the end of the discussion. COM methods have a defined order, if you change the order it won't work so well. If you look at the c or c++ definitions of the itnerfaces in the PSDK you'll find the correct order to use, this is also usually the order used in the documentation but its always worth checking to make sure. Make sure they are in the order IUnknown (implicitly added so don't bother), IContextMenu, IContextMenu2. I'm no expert on COM, the shell interfaces are really my first try, but i've picked up a few things on the way through the docs. I think i'm being lucky and a bit cheeky with my definitions and that its working because the COM interop has to interpret the exported methods into a vtable rather than building it at compile time. I'm going to have a tinker with IContextMenu2 and IContextMenu3 and see what happens later. I do remember reading an article (possibly here ar codeproject) which states that you don't have ti implement inherited interfaces in the using interface but i'm more certain that Mattias is correct.

Can you privode a link, or tell me how to find that definition you used? Because it seems to be contrary to the documentation i've read. I also couln'dt find a useful implementation of IContextMenu and provided my own. While i cant claim its perfect i've not had any problems with the shell crashing in quite a while now so i think i'm at or close to a correct definition. I'd also be interested to see those articles, i've read around COM interop articles a bit lately and i've not found any that specifically mentioned the redefinition argument. IContextMenu2.HandleMenuMsg is defined as HRESULT HandleMenuMsg(UINT uMsg, WPARAM wParam, LPARAM lParam); In c# i'd probably make that [PreserveSig] int HandleMenuMsg(uint uMsg, IntPtr wParam,IntPtr lParam); though of course i'd have to look up the header definitions of LPARAM and WPARAM to be certain of their size/type. Without PreserveSig that would return void instead of int and if you have an error you'll have to throw an exception with an hresul generated using the Marshal class functions. In my limited experience if you do something wrong with your marshalling you end up corrupting the shell memory and eventually it'll either start to behave very oddly or it'll just crash unexpectedly.

I don't think you need the redefinitions of IContextMenu methods in there, they may be causing your the problem when it tries to marshal the interface. Even if your interface inherits another interface, in this case IContextMenu2 : IContextMenu, you don't redefine the members from the original interface. Also, if i remember correctly, there is an entry on Raymod Kim's blog as well an anecdotal evidence that IContextMenu2 isn't very useful. The system checks for IContextMenu2 and if present then tries to use IContextMenu3, if that isn't present it falls back to the original IContextMenu. So you will need to implement the 3 interface for it to work i think. I think your definitions of IContextMeuu are wrong as well. PreserveSig is used to prevent the signiture being changed because typically COM methods will return an HResult value. Your methods aren't returning HResult (or int) values and yet you've marked them with PreserveSig. Either remove the attribute or change the function definitions to match the definitions found in the header files exactly, otherwise i think you're either hiding errors or causing deeper problems which may not be apparent until the shell dies on you.

Or if you want a more dynamic solution look up the IMessageFilter interface. Message filters can be added and removed from windows forms application at runtime.

In which case i'd be very interested to see that, i started trying to implement it myself a few weeks ago and got bogged down in various bits of documentation.

Is each plugin in a different AppDomain?