2013/10/3 Nicolás Alvarez <nicolas.alva...@gmail.com>: > 2013/9/30 Nicolás Alvarez <nicolas.alva...@gmail.com>: >> The registry key should be in HKLM to avoid your >> product-getting-repaired problem (I don't know why that causes a >> reboot, but I think that's beside the point; this shouldn't need a >> reboot-less repair either). So your real problem is now ICE38. I can't >> figure out why it's saying the component installs to user profile. The >> ProgramMenuFolder property should be getting set to the 'all users' >> start menu if you have Package/@InstallScope="perMachine" (which you >> do). >> >> But let's take a step back. Your StartMenuDir component only has two >> things: the RemoveFolder, and the registry key. The shortcut directory >> is not in that component, because directories don't "belong to >> components" to begin with, they are created when needed (in this case >> when creating the shortcut). Is it normal/correct to have the >> RemoveFolder in a different component? Is there any reason why it >> can't go to the main component with the .exe and the shortcut? If so, >> you won't need the registry key at all. >> >> Perhaps ICE38 is getting confused and saying the component installs to >> a user profile because it doesn't install anything at all :) > > OK, I'm now hitting a very similar problem myself... > > I made a simple installer with a single .exe, an advertised shortcut, > and a RemoveFolder for the start menu folder where the shortcut is, > all in the same component, which is what I suggested in my previous > email. That worked just fine, with no need for a registry key... until > I had to add a second executable and shortcut. The whole idea breaks > down if I have multiple shortcuts. I can't put it in one of the > components, because later I may want to put the two exe+shortcut > components in different features, so any of the two components may not > be installed. > > So I moved the RemoveFolder to a different component, inside the > Directory matching the folder being removed. "ICE38: component > installs to user profile, must have HKCU registry key as keypath." I'm > pretty sure I can now say I feel your pain :) > > If the ALLUSERS property is set to 1, ProgramMenuFolder is set to the > "all users" start menu, which is *not* in the user profile, and I > think everything would be safe (I couldn't even override it by setting > ALLUSERS=0 in the command line). Isn't ICE38 wrong in this case?
Time for some experiments. Base setup: Single feature, two components each containing an .exe and an advertised shortcut. The advertised shortcuts are in a subdirectory of ProgramMenuFolder. There's a few more DLL components, not relevant to this. The package has InstallScope="perMachine". Here's a long list of things I tried. 1. No RemoveFolder at all. The folder is being created by the installer on demand, when the shortcut is installed, so it should be getting removed automatically on uninstall, when the folder goes empty. And simple tests show it does work. However, this triggers ICE64, saying the folder could be left orphaned in some obscure roaming-profile scenario which I'm not sure I care about. Can I ignore this ICE? 2. Put RemoveFolder in one of the components with exe+shortcut. Works, no ICE errors. But it wouldn't work if it was possible the components weren't installed (eg. if they were in different features). It also doesn't feel clean, because it would be an arbitrary decision to choose what component to put it in... 3. Put a RemoveFolder in each and every component with exe+shortcut. Works, no ICE errors. Feels silly. Is it a good idea? 4. Create a new component with the RemoveFolder, inside the Directory with the shortcut (ie. the directory being removed): 4a. Component with *only* the RemoveFolder, no registry key. Works in simple testing. But gives "ICE38: Component FolderRemover installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file." 4b. Like 4a, but with a RegistryValue in HKLM as keypath. Works in simple testing. But, as mentioned many times in this thread, it gives "ICE38: Component FolderRemover installs to user profile. It's[sic] KeyPath registry key must fall under HKCU". 4c. Like 4a, but with a RegistryValue in HKCU as keypath. Works, no ICE errors, but every user who launches the application for the first time through an advertised shortcut would get a repair, because the registry key wouldn't exist. 5. Component with only RemoveFolder, registry value in HKLM [sic!], but the component associated to the ProgramFilesFolder directory instead of the start menu subdirectory being removed. This doesn't give the ICE38 error like 4b, probably because ProgramFilesFolder is properly identified as a global directory instead of part of the user profile. This is exactly what WiX 3.7's own core.msi does. Since the component doesn't install any files, I think it doesn't even matter what directory it's associated to... I also looked at what Orca.msi does. It turns out the whole problem with RemoveFolder is moot in Orca, because it installs its shortcut in the root of ProgramMenuFolder, so there's no subdirectory to delete. -- Nicolás ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
