How to create custom context wrappers for Windows?

Question

Problem

Language: C # 2.0 or later

---

I would like to register context handlers to create menus when the user clicks on certain files (in my case * .eic). What is the procedure for registering, unregistering (cleaning) and processing events (clicks) from these menus?

I have a clue that this is related to the Windows registry, but given how many things are in .net, I won’t be surprised if there are convenient ways to make it clean and easy.

Code snippets, links to sites, comments - all this is good. Please throw them at me.

Update

---

Obviously, there is a small problem with creating context menus in managed languages, as several users commented. Is there another preferred way to achieve the same behavior, or should I spend time exploring these workarounds? I am not against it, I am glad that people have made efforts to make this possible, but I still want to know if there is a “right / clean” way to achieve this.

Answer 1

Resistance to writing shell extensions in managed languages ​​- there are many things that can hit if you pursue this route.

Browse this topic for more details. It contains links to do this, if you really need it, and with tips on why you can do this, but shouldn't.

http://social.msdn.microsoft.com/Forums/en-US/netfxbcl/thread/1428326d-7950-42b4-ad94-8e962124043e/

You are back to unmanaged C / C ++ as your real tools here.

Answer 2

This is not a good idea due to possible dependency issues between different versions of the .NET Framework. A shell extension can be expected from one version, while another version may already be loaded by the current application launch.

This thread contains a good summary of the situation.

Answer 3

I made them before in C #. In the end, it is much more complicated than it should be. Once you get the template code, however, it’s easy to deploy new items. I followed this link:

Information Link

Answer 4

While others have already mentioned that writing shell extensions in pure .NET is a bad idea due to framework conflicts, you should still note that:

• There are third-party drivers (see Eldos or LogicNP) that make the side unmanaged for you, which allows you to write managed code that speaks to the native driver, thereby preventing CLR version conflicts associated with the shell.

• A recent MSDN article mentioned that Microsoft has resolved this issue for CoreCLR used by Silverlight. They accomplished this by allowing multiple versions of the CLR to run in the same process, thereby fixing the problem. The author further stated that this fix in Silverlight will be upgraded to future versions of the full CLR. (So ​​in the future it will be entirely possible to write shell extensions in managed code.)

Answer 5

As noted in previous comments, it is not best to write shell extensions in managed languages, but I thought I would use an open source project that does just that :)

ShellGlue is a managed shell extension that is actually quite useful. The source may also be useful for you if you are interested in continuing to write shell extensions in C / C ++.

Answer 6

In addition to the caveats that were mentioned regarding the implementation of shell extensions in managed code, you basically need to do the following:

First, create a COM component in C # that implements the IShellExtInit IContextMenu interfaces. How to create COM components in C # is described here . How to implement the necessary interfaces is described in this article . While the description is intended to be implemented in C ++, you can apply this knowledge to your version of C #.

Your COM component will have a GUID called a class identifier or CLSID. You need to register this identifier with the file type as a shell extension of the context menu:

HKEY_CLASSES_ROOT\.eic\ShellEx\ContextMenuHandlers\MyShellExt (Default) -> {YOUR-COMPONENTS-CLSID} 

Also make sure that you have registered your component correctly, as described in the C # COM tutorial. You should find it in the registry under

 HKEY_CLASSES_ROOT\CLSID\{YOUR-COMPONENTS-CLSID} InprocServer32 (Default) -> C:\WINDOWS\system32\mscoree.dll Class -> YourImplClass assembly -> YourAssembly, version=..., Culture=neutral, PublicKey=... ... 

Good luck ...

Answer 7

As others have noted, shell extensions are currently not practical in Windows development.

I recently asked a similar question , which was answered with reference to the manual, to do exactly what I wanted to do