Making a Windows shell extension in Visual Studio 2010

Question

I'm trying to create an absurdly simple shell extension in C++ using Visual Studio 2010, but I can't even seem to get the examples out there to work as a starting point.

I'm using Windows 7 x64.

I've tried this Visual Studio template, but once I get the template to work in VS2010, I have a host of errors that I'm not sure how to fix.

I've tried The Complete Idiot's Guide to Writing Shell Extensions, and once the demo compiles all the right registry settings etc. are created but no context menu appears.

I've looked at this C# COM Interop example, but I've been left confused as to whether it is safe to use C# thanks to this article*, but it looks like I might be OK if I use .NET 4 because it supports in process side-by-side CLR hosting.

• in short: historically two versions of .NET cannot run in the same process, and the way shell extensions work is they inject themselves into a process. So if .NET 3.5 gets injected into a .NET 2 process - bang

So, can I use .NET 4.0 now?

Is there a working, downloadable, VS2010 solution that adds a simple shell extension?

I used to be not so bad with C++ back in the day, but after years of moulding to .NET I'm quite rusty, and as such, fiddling with the details to fix the host of errors I'm getting on the existing examples is proving... fiddly!

I could really do with a clean slate to start with that I can break myself and figure out what I did wrong!

Answer 1

I struggled with this for a while and had limited success with the code project article due to x64 issues and SDK differences.

I recently picked the project back up and started over using the MS all-in-one code sample and I am very pleased. It makes a simple example context menu and x64 works out of the box: http://code.msdn.microsoft.com/windowsdesktop/CppShellExtContextMenuHandl-410a709a

To get it running on your machine:

1. download the code via the all-in-one sample browser or use the direct link.
2. Open project in VS under admin rights
3. switch build config to x64 and build it
4. Kill all explorer sessions
5. Locate the new dll and run regsvr32.exe .\CppShellExtContextMenuHandler.dll
6. open explorer again and right click a .cpp file to see the new menu
7. remove it by running same command with /u flag

My next step is to get debugging working and I think this may do the trick: msdn

Answer 2

On Windows 7 x64 for a C++ extension you need to build it as an x64 project. In Visual Studio 2010 there is an option on the ATL Wizard to create a shell extension project that provides preview window support, thumbnails and Windows Search support. I recently used this and once built, nothing seemed to happen. However, switching the project configuration to build an x64 dll got it working.

With regards to using .Net - Explorer now launches plugins in a separate sub-process. So loading a shell extension that links to .net 4.0 does not contaminate everything with that version of .net as only the hosting subprocess will actually load that CLR. You can see this using a preview extension as a new process (prevhost) gets launched to contain this.

Answer 3

I got this one working: http://www.codeproject.com/Articles/174369/How-to-Write-Windows-Shell-Extension-with-NET-Lang

Make sure you use the right RegAsm.exe for de/registering it:

• 32-bit platforms: Compile for x86/Any CPU. Use C:\Windows\Microsoft.NET\Framework\vXYZ\RegAsm.exe.
• 64-bit platforms: Compile for x64/Any CPU. Use C:\Windows\Microsoft.NET\Framework64\vXYZ\RegAsm.exe.

(XYZ is the version of the .NET Framework you used for compiling.)

Note, however, that Microsoft recommends against using .NET for shell extensions.

Answer 4

The short answer to your 'can I use C#' is no. This is from Microsoft’s Guidance for Implementing In-Process Extensions. "One runtime of particular note is the common language runtime (CLR), also known as managed code or the .NET Framework. Microsoft recommends against writing managed in-process extensions to Windows Explorer or Windows Internet Explorer and does not consider them a supported scenario." The problem arises because only a single version of .NET can be used in an application and there is no way to enforce that limitation if multiple .NET extensions are in use.