Hi all, I'm trying to collect complaints with shell extensions and the various setup/registration issues that fall out of them. I hope to fix some of them, and provide tools to make some others easier. I'm going to keep the main discussion up on by blog starting with http://blogs.msdn.com/jamesfi/archive/2007/08/10/installing-shell-extensions-please-complain-here.aspx , but I'll keep monitoring this thread for complaints and other comments. Please especially complain about any installation step that would require a custom action to do it in an MSI. Thanks, -- James Finnigan [MSFT] ( http://blogs.msdn.com/jamesfi ) This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.
James Finnigan [MSFT] wrote: > I'm trying to collect complaints with shell extensions and the various > setup/registration issues that fall out of them. The big problem that comes up again and again is that you usually can't upgrade a shell extension without requring a reboot, because the DLL is stuck in the Explorer desktop process. In some cases, once the shell has loaded an extension it never releases it again. In other cases the shell does release the extension, but the DLL still remains loaded forever because the extension object was created on a background thread, and CoFreeUnusedLibraries appears to only unload DLLs that were originally loaded in the same apartment. -- Jim Barry, MVP (Windows SDK)
Jim Barry wrote: > James Finnigan [MSFT] wrote: > >>I'm trying to collect complaints with shell extensions and the various >>setup/registration issues that fall out of them. > > > The big problem that comes up again and again is that you usually can't upgrade a shell extension without requring a reboot, because the DLL is stuck in the Explorer desktop process. In some cases, once the shell has loaded an extension it never releases it again. In other cases the shell does release the extension, but the DLL still remains loaded forever because the extension object was created on a background thread, and CoFreeUnusedLibraries appears to only unload DLLs that were originally loaded in the same apartment. I'll second that motion.... make *all* shell extensions readily unloadable so that their corresponding DLLs get properly unloaded from memory on-demand [excluding coding errors in extensions where COM object reference counts don't get zeroed out properly]. I've had our sales people, tech support people and install kit builder people all complain about the need to unregister the extensions & then reboot before the updated DLL files could replace the older ones. -- Chuck Chopp ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com RTFM Consulting Services Inc. 864 801 2795 voice & voicemail 103 Autumn Hill Road 864 801 2774 fax Greer, SC 29651 Do not send me unsolicited commercial email.
>The big problem that comes up again and again is that you usually can't upgrade a shell extension without requring a reboot, I'll third that one - it was the first problem I thought of too. I have to tell my users to reboot (or log off/on to close Explorer) when upgrading, otherwise it appears as though nothing has happened because the old version is still activated after the update. Dave
James Finnigan [MSFT] wrote: > Hi all, > > I'm trying to collect complaints with shell extensions and the various > setup/registration issues that fall out of them. I hope to fix some of > them, and provide tools to make some others easier. > > I'm going to keep the main discussion up on by blog starting with > http://blogs.msdn.com/jamesfi/archive/2007/08/10/installing-shell-extensions-please-complain-here.aspx > , but I'll keep monitoring this thread for complaints and other comments. > > Please especially complain about any installation step that would > require a custom action to do it in an MSI. OK, I'm digging back into memory here... I vaguely recall something posted here a few months back, I think regarding a problem with deskbands and/or infobands that won't show themselves until the second time that they are accessed. Here's the Google Groups link for it: http://groups.google.com/group/microsoft.public.platformsdk.shell/browse_frm/thread/8897d15df2cc6ea8/4c15e85b7db01f76?lnk=st&q=&rnum=2#4c15e85b7db01f76 I haven't encountered the problem, personally, but it stuck in my head as one of the next enhancements to the application that uses my NSE is to implement deskband & infoband shell extensions. -- Chuck Chopp ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com RTFM Consulting Services Inc. 864 801 2795 voice & voicemail 103 Autumn Hill Road 864 801 2774 fax Greer, SC 29651 Do not send me unsolicited commercial email.
Installing NSE on 64 bit environment is little bit tricky. If the NSE supports common dialog browsing, Then it would be registered for 32 bit application too. otherwise 32 bit applications will not load the NSE in their SaveAs/Open dialogs. The NSE will disappear for 32 bit applications. Two copies of the NSE's application folder should be created each under "Program Files" & "Program Files (X86)" NSE's all registry entries should be created for both 64 bit 32 bit portions of the registry.\ Regards Prakash
