> > > 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?
Windows Installer caches a copy of your MSI but it strips out any embedded cabinets. You'll need the original source for repairs. I'll let somebody with more knowledge provide advice. I have heard mentioned that Windows Installer requires that the MSI package filename does not change (probably for Repair scenarios). You may want to make sure the bootstrapper EXE extracts the MSI packages using consistent naming every time. > > > 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? If I remember correctly, Visual Studio setup projects only allow a single Feature. Features and Components are a Windows Installer concepts. ComponentGroups and FeatureGroups are WiX concepts to help organization. Make sure to follow the Component Rules. > > > 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. You should be able to set the impersonation appropriately to launch your exe as the user. > > > 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? The %ProgramFiles% filesystem is readonly. If you want configuration that is *not* modified by the installer at install time then you should place those configuration files in writable filesystem. There is a place for such files at the "system-level" but I can't remember where it is. I believe the folder physically maps to C:\ProgramData but I forget what the FolderId is for it. Let's assume you copy the configuration files to "C:\ProgramData\Classic Shell". The real question is "How do you migrate values in the current configuration file to the new configuration file on upgrades"? You may need a CustomAction (or more) to do this. > > > 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? The WiX projects are MSBuild-based. Your solution will contain C++ projects and WiX projects. Any additional automation (if any) will just need to happen in the WiX projects (probably under a BeforeBuild target). Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail ------------------------------------------------------------------------------ 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
