Thanks for the response. Moving the RemoveExistingProducts route seems to be my best/easiest option, even though it overwrites file changes... at least I get a full/working install set. A pre-backup and post-install-hand-merge will be necessary in many cases.
Regarding moving forward... any advice on if/when/how I should transition to a single-File-per-Component strategy? Thanks, Mark. ________________________________ From: Blair <os...@live.com> To: General discussion for Windows Installer XML toolset. <wix-users@lists.sourceforge.net> Sent: Mon, February 22, 2010 6:30:28 PM Subject: Re: [WiX-users] missing install files The easiest way out is to move the RemoveExistingProducts action to be before InstallInitialize. However, there are situations where that doesn't seem to work, and it carries (sometimes significant) upgrade costs. Any better solution would involve a good in-depth analysis which is best done one-on-one and involves a time commitment because recovering from component rule violations for already released products has few good solutions and many severe limitations and have to be reviewed case-by-case since each possible "rule-of-thumb" has side effects that are often subtle. Maybe now would be a good time to get that book on Windows Installer written (but where will I find the time?). -----Original Message----- From: Mark Pietras [mailto:mpiet...@yahoo.com] Sent: Monday, February 22, 2010 1:39 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] missing install files In short: when I install my newer msi package over an older existing install, the old files are deleted but are not replaced with their newer versions. I end up with all "overlapping files" gone, and only newly-added files remain. For example: Old WXS: <Directory Id='folder_folder' Name='folder'> <Component Id='folder' Guid='xxxx'> <File Id='f1' Source='f1' /> <File Id='f2' Source='f2' /> <File Id='f3' Source='f3' /> </Component> </Directory> New WXS: <Directory Id='folder_folder' Name='folder'> <Component Id='folder' Guid='xxxx'> <File Id='f1' Source='f1' /> <File Id='f2' Source='f2' /> <File Id='f3' Source='f3' /> <File Id='f4' Source='f4' /> <File Id='f5' Source='f5' /> </Component> </Directory> After installing new over old, my resulting folder only has f4 and f5... I've lost f1 f2 f3. I understand now that I probably shouldn't have done it this way... based on what I'm reading it seems a component per file would have been the way to go but it wasn't clear at the time of initial creation that this would be an issue... didn't know to look for the solution of a problem I didn't know I had. Anyway, I've read through a few similar threads and I honestly just don't get what the easiest way out of my situation is. My "old" package has 30 or so directory components with lots of files and directories under each component. Of course now I have this "old" package installed in lots of customer locations. My situation is further complicated by the fact that some customers have modified some resources and I don't want my update to overwrite anything they've changed by hand. I've tried a few things, unsuccessfully: 1) tried simply changing the component Guid... no change in behavior... only the new files result. 2) tried changing <RemoveExistingProducts After="InstallFinalize" /> to <RemoveExistingProducts After="InstallInitialize" />... which resulted in me getting all the files correctly, but customer-modified resources were gone. 3) tried adding <Property Id='REINSTALLMODE' Value='amus'/>... resulted in some behavior I didn't understand where all the feature options were X'd out... but selecting them to install still resulted in only new files. 4) tried making a component per file with all new Guids... that too resulted in only the new files. Am I missing something basic I hope? Any help appreciated in recovering from this situation and making it easier in the future. Thanks. ---------------------------------------------------------------------------- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
