Yes, they are ;) We have a base feature "MainFeature" and subfeatures "ProgramOne", "ProgramTwo", "ProgramThree"...
The main feature only includes some general registry components (paths, global settings). Each program feature contains only components they need to run - so some shared libraries are referenced in all programs, but some are just for one special program. All the programs as part of big package and can communicate between each other, but also each programs can work on each own. (Let's say we have the programs are "Calculator" and "TableEditor". When both programs are installed you can use "Calculator" from within the "TableEditor" or you can save results from "Calculator" to tables using "TableEditor".) We are using External UI application to manage our installation process, which gathers data from the user, downloads the required CAB fiels and then calls Windows Installer API: MsiInstallProduct(MsiPath, MsiParams) The MsiParams looks like: "INSTALLDIR=C:\Program Files\Fine\Programs\ COMMONDIR=C:\Program Files\Common Files\Fine Shared\ ADDLOCAL=MainFeature,ProgramOne,ProgramTwo" The Msi uses Major Upgrade without the "MigrateFeatureStates" action, so programs not referenced in ADDLOCAL get uninstalled. When we are doing an update, the External UI application always analyzes the current installed version and tells the Windows Installer all the features to (re)install. But we would like to somehow be able to select which programs/features not to remove and reinstall during the update. The ideal solution would be: "ADDLOCAL=MainFeature,ProgramOne KEEPOLD=ProgramTwo" Generally we are not removing files from release to release, so no files would get deleted. In the special case some file will be deleted from the newer version we are OK with the Windows Installer deleting the old one so the new MSI file correctly references all the KeyPaths installed on the user's computer. I'm open to any other ideas, which would help us solve this issue. This is not supported solution for our customers, but we need them to have a way to use different versions of programs from our package. (We know of some compatibility problems when ProgramOne 1.0 doesn't properly communicate with ProgramThree 2.0 and can crash) Thank you Ondrej Zarevucky Blair wrote: > I hope your "programs" are implemented as Windows Installer Features in your > MSI package. > > -----Original Message----- > From: Ondrej Zarevucky [mailto:ondrej.zarevu...@fine.cz] > Sent: Thursday, December 03, 2009 8:25 AM > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] Partial major upgrade? > > Hi, > we have prepared one MSI package with the whole set of our programs > (many of our customers buy more than 4 programs which share the same > libraries) and we try to persuade our customers to buy all the programs > in the same major version so it's not a problem, but there was one case... > > The customer didn't want to pay for the upgrade of the old programs > (let's say version 1.0), but wanted to buy a another new one (version > 2.0). The programs are written in a way the version 1.0 programs can use > the version 2.0 libraries. > > My question is: > - how to perform major upgrade (this is how we implemented updates), but > leave some program files in lower version? > > My ideas: > A) temporarily change the File table in MSI database to older file > version - MSI then shouldn't overwrite them nor delete them, because we > have sequenced RemoveExistingProducts action after *InstallExecute* action. > B) upgrade the package to version 2.0 and then install 1.0 as another > instance using Instance transform - we are afraid it would become hell > to service, when the user buys upgrade of programs scattered in > different instances > C) remove the automatic major upgrade step across major versions (1.0 to > 2.0) and two independent install of new version and unistall of the old > version. If the user chases not to update some programs, the uninstall > doesn't remove all the features. This is still problematic for servicing > and doesn't allow good rollback scenario if things go wrong > (Transactions are supported in Windows Installer 4.5, but we need to > target 3.1) > D) split the package to have one msi package for each program - this > allows complete independency, but has problems with Add/Remove dialog, > no good rollback support, is slower to install, and the installation > media requires to be much larger :( > > Can you help me, how to solve this issue? I'm currently inclined for the > temporary File table change, but I'm not sure, how to do it properly. > > I've looked at this post: > http://www.joyofsetup.com/2007/07/01/semi-custom-actions/ > which uses WcaAddTempRecord, which uses MsiViewModify(..., > MSIMODIFY_INSERT_TEMPORARY, ...) > Sadly, I didn't find any MSIMODIFY_UPDATE_TEMPORARY, only > MSIMODIFY_UPDATE ( > http://msdn.microsoft.com/en-us/library/aa370519(VS.85).aspx > <http://msdn.microsoft.com/en-us/library/aa370519%28VS.85%29.aspx> ) > > Thank you for any help > Ondrej Zarevucky > > ---------------------------------------------------------------------------- > -- > Join us December 9, 2009 for the Red Hat Virtual Experience, > a free event focused on virtualization and cloud computing. > Attend in-depth sessions from your desk. Your couch. Anywhere. > http://p.sf.net/sfu/redhat-sfdev2dev > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ------------------------------------------------------------------------------ > Join us December 9, 2009 for the Red Hat Virtual Experience, > a free event focused on virtualization and cloud computing. > Attend in-depth sessions from your desk. Your couch. Anywhere. > http://p.sf.net/sfu/redhat-sfdev2dev > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
