I have followed the same approach to implement the shell extension using dot NET 4.0. Everything is working fine. This code is bundled in MSI(version 1.0) and released to customer. Later I we have found that there is an issue in the project and fixed it. Then we gave the service pack MSI for this bug fix(Version 1.1). During upgrade the explorer.exe is getting killed. How I can prevent killing the explorer.exe ?
So I have had some issues trying to get this to work on Windows 7 64-bit. I did some searching, and found that when loading RegAsm.exe to register the assembly, you need to be sure you are running from the Framework64 folder. (example: "C:\Windows\Microsoft.NET\Framework64\..." If you register the DLL from that RegAsm.exe, it will work on x64. I am pretty sure this will apply for any other x64 version of windows.
I can't seem to get it to work by changing only the extension name of the parameter supplied to RegisterShellExtContextMenuHandler() and UnregisterShellExtContextMenuHandler(). Am I missing something?
- Ok, i edited this msg, now I have made it to work with .txt, .cs, and other less common files, except for PNG, JPG, JPEG, BMP, and other common image files. What I'm developing is an auto-uploader for image files. I have Picasa (Google photo viewer) installed. And it seems (I think) it's the reason why the shell extension doesn't work well with the image files. I think there is some sort of conflict.
I noticed though by checking on the registry that if for example, I use the .txt extension to extend the context menu, a new registry entry for "HKEY_CLASSES_ROOT\txtfile\shellex\ContextMenuHandlers" is made. Not for the "HKEY_CLASSES_ROOT\.txt\shellex\ContextMenuHandlers". However, even if this is the case, the context menu works well.
And for my JPG files, the same is true. A new entry is made at "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\jpegfile" and not at "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.jpg". However, even if this new entry is made for the jpegfile key, no new context menu pops-out, only the old Picasa Menu.
How did Picasa integrate its shell extension with Windows? And how do I circumvent this conflict? I have not tried uninstalling Picasa yet. I will try and I'll see if there are changes to the behaviour. What I'm really worried of is if there are special cases to consider for .jpeg, .png, .gif, and other image files when it comes to extending the shell context menu.
Additionally, if I install/register manually, or using the package as compiled with the solution, after installation/registration, it can't uninstall directly because explorer is still using the dll even if i manually unregistered it using the command prompt. My workaround has been to taskkill the explorer.exe before reinstalling again during the debugging phase.
I am looking for a way to add a column for file/path length in windows explorer. For all users in a windows domain. This is important for me because our projects are copied to CD/DVD and there are built in restrictions in the software we use. Most of my users have Win 7 64bit, but I have 4 win XP and 2 Vista users also.
Additionally, if there is a way to change the color of the resulting text when it reaches a value of 106 characters length, and again at a value of 212 characters length.
Hmmm...there is a potential problem here that can make a mess. I think it is a bad idea to use .NET to extend an application intra-process. What happens if there is another extension used by Explorer written in 2.0 and yours is 3.0+? If it loads before you, then you can't load the 3.0+ version. Shell Extensions are intra process for Explorer. If you load first, then no problem as there is backward compatibility, but if the other app loads first you cannot "up-version" the .NET assembly that is already loaded.
How does this solution avoid this potential problem of incompatibility with other running .NET based extensions?
I didn't rate this article. Its a good tutorial but there is a real versioning issue here as you don't control what other pieces are in place. Perhaps if you limit yourself to using .NET 2.0????
I've read the article(s), too, and you are right, .net 2 - 3.5 are not the right choice if you either want to write a shell extension or to use them. But in .Net 4 these limitations has been removed. If the user uses .Net Shell extensions which are written in < .Net 4 than it's his fault .You as a programmer cannot control which extensions the user has installed. In my opinion, you could check if there are such extensions (they are all registered in the registry) and show a warning.