(keeping the thread on the list so future generations can benefit) The source list is described here: http://msdn.microsoft.com/library/aa369795.aspx and here: http://msdn.microsoft.com/library/aa371859.aspx along with a few other places. It is the list of directories that Windows Installer will search to find the non-stripped version of the MSI for each installed product whenever it needs it (you get a ResolveSource prompt when that search fails). The list contains just the directories: the MSI's name is separately stored and can't be changed. When a product is uninstalled, the associated source list is automatically removed (along with all other metadata related to that product). The content of that source list, however, is not (so you would need to remove your cached MSI when your product is removed).
A component is Windows Installer's atomic unit of installation: it consists of resource(s) (files, registry values, etc.) that assume one identity (the keypath of the component) and one name (a GUID for cross-package use and an identifier for use within a given database) and the identity is used to determine the entire component's "health" and status: for that reason it is generally encouraged that you have only one file per component. Search for "Component Rules" to get a feeling for what you "need to know" to avoid creating packages that can't be upgraded/serviced/cleanly removed. A feature is the fundamental user selection "grouping" of what is or isn't installed (in MSWord, for instance, a spell-check for any arbitrary language dictionary is a feature, as the program can run with or without it). That appears analogous to your use of the term "component" in your first email in this thread. A product is a collection of features and components (any given component may be a member of more than one feature but must be a member of at least one or it could never be installed, removed, or even maintained) that can exist independently of any other product, is instanced such that only one can be on any given computer at a time. Products can be tied together in a family via an UpgradeCode which is typically used to remove old versions and prevent downgrading (overwriting a newer version by replacing it with an older one). Products are supplied via a package (an MSI database file) which provides the complete definition of an arbitrary instance of a product. MSI can copy or move files (which includes renames) but typically it moves them after overwriting them. You can extend MSI via custom actions which you can use to rename your .ini files. WiX provides for the use of just about every feature available in Windows Installer (in fact, if one were so inclined, you could reauthor every other MSI file in WiX). -----Original Message----- From: i...@roadrunner.com [mailto:i...@roadrunner.com] Sent: Friday, June 18, 2010 12:11 PM To: Blair Subject: RE: [WiX-users] Can this be done with WiX? ---- Blair <os...@live.com> wrote: > > 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. > > Burn and some other bootstrappers deal with this. Another solution I have > seen is a custom action that caches the original MSI during the installation > and adds the cached location to the "Source List". I'll check out Burn. But I would prefer to write my own bootstrapper. So I just need to know where to put the MSIs, how do I name them, and will the uninstaller know to delete them in the end? Where can I read more about that "Source List"? > > > 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. > > Just to add to this: Most of the time, you want a single file per component. > You want to group your components into your features. You can select features > to install via either the command-line or the UI. Silly terminology question - I know what a file is, I'm guessing a "feature" is something that the user can select/deselect, but then what's a "component"? Can I have features, with files inside? > You could possibly "read" the customizations from the INI files and write > those out to the new INI files using built-in support in Windows Installer > for writing INI files (the built in support for reading INI files applies > only to INI files in the windows system directory) and a custom action that > reads the customizations from the previous INI files that you will apply to > the upgrades. It is not that simple. At the moment the format of the ini files is not that stable and I want to keep the it open for me to change it as I see between versions. It will be very tricky to extract the customizations from one version of the ini files and apply to the next. So for now the only practical solution is to let the users worry about that. That's why I want to keep the old files around, so they can use them as a reference (not as an exact replacement). I'm not proud of the current system, but I don't have the resources to do something smarter. ------------------------------------------------------------------------------ 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
