> > 1) I need a single EXE that can be installed on both 32-bit and 64-bit > > platforms (Vista and Windows 7). Most of the files (art assets, help > > files) are common between platforms. There are 32-bit and 64-bit > > executables, which need to register themselves in the registry > > (self-registered COM). There are some registry keys, which need to be > > set correctly (bypass the 32-bit redirection on 64-bit systems). I am > > told that (at least with Visual Studio) it is not possible to have a > > single MSI file that targets 32-bit and 64-bit platforms. I think the > > problem was that you can't run the 64-bit MSI on 32-bit OS, but a 32-bit > > MSI can't contain 64-bit modules. Can WiX do this in a single package? > >
> 1) This isn't a limitation of Visual Studio or WiX. This is a limitation with > Windows Installer. You'll need to have two MSI packages. A bootstrapper might > help you consolidate them so that it appears like one installer. That's what I'm currently doing. I compile 2 MSI files and package them in a bootstrapper EXE. The EXE extracts the right MSI into the Temp folder and runs it. The problem is that the Repair action looks for that MSI but it's long gone. It doesn't help that I'm creating a unique temp file name, so even when the MSI exists, it will have a new name, so Repair can't recognize it. Is there a better solution? > > 2) I have 2 components. With few exceptions, every installed file > > belongs to one component or the other. I want to provide UI options for > > selecting the components to install, as well as command line options for > > silent install. I also want an option to specify the install folder, > > ideally with a command line option support too. > 2) These sound like Features in Windows Installer parlance. As you organize > Components and ComponentGroups you'll want to ultimately have only two root > Features that aggregate the components correctly. Am I right to think that such components/groups are not possible to create with a Visual Studio setup project? > > 5) As the last step of the install process I want to launch an > > executable, but I want to launch it as the currently logged-in user, not > > as SYSTEM. (Looks like msiexec runs as SYSTEM, so any child process is > > SYSTEM by default). > > > 5) You should be able to author a CustomAction to do this, but it sounds like > you want to restart Explorer.exe and that seems dangerous to me. I'm not talking about Explorer.exe only, but for my own app. Is it possible for a CustomAction to launch my program as the logged-in user instead of SYSTEM? That's a limitation I'm having with my current installer. My solution is to do the launching in the bootstrapper, but that's not ideal. > > 7) There are some ini files, which the user can modify. During uninstall > > or upgrade I want to present the option to rename the files to ini.bak > > so the user modifications are not lost. Ideally the uninstaller can > > recognize which files are modified (by comparing the timestamp with the > > original). Less ideally the uninstaller renames all ini files. Least > > ideal, the uninstaller runs a separate executable that does the work. > > The uninstaller should provide the EXE with the installation path (like > > C:\Program Files\Classic Shell). > > > 7) You should have per-user configuration files stored in the users profile. > You can then do what all other installers do and leave them there. If the > user reinstalls they'll have all their old configuration files available and > ready to use. The %ProgramFiles% filesystem is supposed to be readonly so you > don't want user-modifiable configuration files there. The thing is that every new version adds/removes features or changes the syntax of the ini files. So ini files from an older version are potentially incompatible. My project is a kind of system utility, so I think it is acceptable that only admins can edit the configuration files. I haven't had any complaints from the users about this, so I'd like to stick with the current design. Is it possible to do this through WiX scripting, or the custom action is the only way to go? > > 9) Ideally the build process will be integrated into Visual Studio. > 9) WiX has Visual Studio integration. Automating some of the bits that it > doesn't do automatically is not difficult if you learn/understand MSBuild. My code is all native C++, and in Visual Studio 2008 C++ doesn't use MSBuild. Is it going to be a problem to mix VCBuild and MSBuild projects together? ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
