Nicolás, I like your theory… It seems very plausible. Unfortunately, the .exe is versioned, and so is every one of its .dlls. I double-checked by using Explorer to examine the Details page of each file's Properties. The icon is taken from the .exe file, so there isn't even a data file that could be unversioned.
I believe the reboot happened automatically, and nothing even popped up as a warning. Nobody knew why the system was being jerked out from under them. We had to look in the log files to determine what was happening. -- Charles On Friday, October 4, 2013 at 1:42 PM, Nicolás Alvarez wrote: > I have a theory on why the reboot may have happened, if the .exe file > is not versioned (which I asked but didn't get an answer yet). > > As others said before, because the registry key is in HKCU, when > launching the advertised shortcut for the first time in a user > account, the installer will notice the registry key isn't there and > trigger a repair of the feature. Now, if a file is not versioned, the > file replacement rules say it will get replaced unless the installed > file is newer than the one shipped in the installer (because the user > may have edited it, and expects to keep the edits). So if the .exe is > unversioned, the repair triggered by the shortcut will replace the > file (even if it's identical). However, if another user in the > terminal server is *running* the application, the .exe file is in use, > so the installer will have to reboot in order to replace the file! > > Did the installer reboot automatically or did it show a prompt to the > user saying files were in use and *offering* to reboot? > > -- > Nicolás > > 2013/10/4 Phil Wilson <phildgwil...@gmail.com > (mailto:phildgwil...@gmail.com)>: > > We really need a verbose log to see what's going on. If potentially any > > kind of repair, including right-click on the MSI or even applying a patch > > later on, causes a reboot then the underlying issue isn't the repair it's > > the reboot. It may be an in-use file, it may even be a ScheduleReboot (or > > ForceReboot) action with an incorrect condition. It's typically futile to > > prevent repair because there are several ways they can be initiated, > > shortcuts being just one of them. > > > > Phil Wilson > > > > > > On Fri, Oct 4, 2013 at 7:10 AM, Charles Jenkins <cejw...@gmail.com > > (mailto:cejw...@gmail.com)> wrote: > > > > > Nicolás, > > > > > > Wow, that's a lot of information, and I'm not sure I'm interpreting it > > > correctly. It sounds like option 5 is closest to ideal. Is that right? If > > > it sounds like the right answer, can you post an example showing how to > > > replicate it? > > > > > > -- > > > > > > Charles > > > > > > > > > On Thursday, October 3, 2013 at 11:38 PM, Nicolás Alvarez wrote: > > > > > > > 2013/10/3 Nicolás Alvarez <nicolas.alva...@gmail.com > > > > (mailto:nicolas.alva...@gmail.com) (mailto: > > > nicolas.alva...@gmail.com (mailto:nicolas.alva...@gmail.com))>: > > > > > 2013/9/30 Nicolás Alvarez <nicolas.alva...@gmail.com > > > > > (mailto:nicolas.alva...@gmail.com) (mailto: > > > > > > > > > > nicolas.alva...@gmail.com (mailto: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 (mailto:WiX-users@lists.sourceforge.net) > https://lists.sourceforge.net/lists/listinfo/wix-users > > ------------------------------------------------------------------------------ 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
