Installing shell extensions - please complain here
So... I've been looking more closely at Wix and I think I'm going to build some custom actions to do a really good job installing shell extensions. Which ones do you find most problematic? I realize this is a bit of a change of pace for the blog, so I'll probably hit a few other forums, but please feel free to add comments/complaints about which extensions are problematic.
Maybe you've already done the work to install these properly, but in some cases that can be quite complicated and I could see a lot of folks just accepting some minor bugs and moving on.
I'll start:
Protocol Handlers (https://msdn2.microsoft.com/en-us/library/bb266527.aspx) and Schema Extensions (https://msdn2.microsoft.com/en-us/library/ms647576.aspx). Both of these require custom actions to be installed correctly - and there's no standard for it so everyone is probably doing it themselves which is going to lead to some really inconsistent behavior. None of that is going to help system stability at all.
Another one I came across recently was installing a shell folder that should appear on the desktop. I added it to the desktop namespace but until the user refreshes the desktop it isn't going to appear. You need to send a SHChangeNotify to get it to show up without user intervention. Anyway, there's no standard action for that. So unless you can accept a shortcut to the shell folder (which sends a notification), you'll want a CA there as well. And there again, you want to send as minimal a notification as possible to avoid having the system reload everything when all that you needed is a new icon to show up.
File Associations:
This one is going to be a bit of a laundry list of issues, but I'll start off the first couple issues.
- If previous handlers didn't register under openwith then your registration may blow away any record that they wanted to handle that file association.
- If you register under a meta-type like TXTFile and then someone else claims .txt then you don't get invoked at all.
- Man that thing is complicated. Way, way complicated. (I'm still learning the subtleties - feel free to correct me if I miss a beat.)
So there's a start - let me know as you come across other issues.
Cheers,
James
Comments
Anonymous
August 31, 2007
When upgrading I have to tell my users to uninstall the existing version, reboot (or just log off/on to ensure Explorer closes) and then install the new version. If they don't reboot (close/restart Explorer), Explorer keeps the older shell extension loaded with the result that it appears to the user that the new installation hasn't happened. Please fix Explorer.Anonymous
August 31, 2007
@David Lowndes Thanks - I think this issue should be a little better with the restart manager on Vista+, but I'll follow-up to make sure that it's addressed completely.Anonymous
September 01, 2007
James Finnigan of Microsoft plans to build some custom actions for installing shell extensions, and he'sAnonymous
September 03, 2007
Capturing some feedback from the newsgroups: http://groups.google.com/group/microsoft.public.platformsdk.shell/browse_frm/thread/8897d15df2cc6ea8/4c15e85b7db01f76?lnk=st&q=&rnum=2 Isajanyan wrote: > Whoops - I'm sorry, the problem is not the namespace extension, but an > info band I create. Namespace extension folder appears, but the info > band doesn't until explorer is restarted. Any tips please? What kind of band are we talking about? Explorer bars and tool bands should become available in newly opened Explorer windows without having to restart Explorer. They won't show up in existing windows, though. For desk bands, there is a strange Windows bug that stops a newly registered desk band from appearing in the taskbar's popup menu until the second time it is accessed. -- Jim Barry, MVP (Windows SDK)Anonymous
September 04, 2007
Hi, I have an interesting problem about adding menu items to Windows Explorer context menu. Details below: I have used a sample (ShellExt) from Microsoft Platform SDK for Windows Server 2003 R2. After some changes, I have built the sample and got ShellExt.dll file. Then, I have registered the extension (using ShellExt.reg). Till now, everthing goes well. But the interesting thing is: I have two computers which have the same operating system (Windows XP SP2). The .dll file runs perfectly at first computer and adds menu items to Windows Explorer context menu, but it does not do the same task at second computer. At first step, I have examined and compared all related registry entries of two computers. They are same. Secondly, using a program which is called "ShellExView", I have tried every non-Microsoft products extensions one by one (disabling and enabling them) to clarify whether the failure stems from them or not. Additionally, "ShellExView" shows that the extension ShellExt.dll runs perfectly at the second computer. DebugView shows all messages at first computer but nothing at the second. After a long research on internet, I have failed to find any clue about this kind of problem. May be it seems very strange but the only difference between two computers is: The background color of context menu is gray at first computer, and white at the second. Thanks in advance!Anonymous
September 05, 2007
@CLMan - perhaps you could use the contact form to send me a link to the .reg file. I'll take a look at the registration and let you know where it might be going wrong. FYI - ShellExView is a nice tool, but it's far from a complete listing. Thanks, JamesAnonymous
October 05, 2007
SHChangeNotify and Vista is what I'm currently struggling with. We are authoring a WIC codec. It has to be elevated when called. I have tried several versions of the WIC workarounds to run this from a DLL, but I couldn't ever get it to work. I ended up having to create an EXE that just calls SHChangeNotify, and sometimes this works. Some WIX magic to handle this correctly on all Vistas would be awesome.Anonymous
October 06, 2007
Also, odd things seem to happen when users disable UAC and try to use or install a shell extension.