So we've got this 32-bit software package that is installed on both Win XP and Win 7 machines.
The current issue that I'm looking at is that when installing part of the package, registry values are written to add an executable in the package to the windows context menu. These registry values are part of a wix fragment that is generated by heat from a dll that is part of the process (ie. a dll of the executable).
The problem is that while it works on windows xp embedded, on windows 7, not only does the application NOT show up in the context menu, it also breaks something so that the "New Folder" option is removed from all context menus. Uninstalling the application doesn't work, but it can be fixed by adding the registry settings from this site: http://social.technet.microsoft.com/Forums/en-IE/w7itprogeneral/thread/97de8a2a-12f2-4381-a409-a78f4ae551cf
Of course when you install a new build, then it gets wiped away again, and as developers, sometimes we're installing and uninstalling 5-6 builds a day. I've confirmed that it is those particular registry settings by removing them from the installer and building and installing it, and the "New Folder" option happily stays where it is.
So my question is: is there a problem with heat generating valid registry values to write for a 32-bit application/dll to be added to the context menu on windows 7? (for complete disclosure, I'm using win7 64-bit, but we've had the same issue on win7 32-bit, but we haven't tried vista)
Heat simply captures the registry keys written during the DllRegisterServer() call. If you are not getting the registry keys you expect, then look at the DllRegisterServer() code to see what it is doing. Also, you may find it more useful to capture the registry keys once, verify they are correct then not use heat.exe any longer.
That's my preferred approach.