Ok, I tried the deferred custom action, but I use Session, so that won't work.
I'll look at chaining, but I guess I'd better see if that delete stuff is really necessary for our use. I still wouldn't mind any additional remarks/advice about the MSP and the upgrade MSI though. Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 [email protected] Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada -----Original Message----- From: Peter Shirtcliffe [mailto:[email protected]] Sent: April-17-12 12:25 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] MSP question The CA will run in both the patch and minor upgrade if not conditioned appropriately. Custom actions that change the machine state should be deferred, not immediate, which affects when they run. That might be something to do with it but it's strange how it affects some files and not others. It might be best instead to provide a clean-up tool and run it first from a chainer/bootstrapper as long as that won't touch any version installed via MSI. -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: 17 April 2012 17:00 To: [email protected] Subject: Re: [WiX-users] MSP question No difference in the source. The full MSI (with the commandline suggested) seems to preserve the files correctly but oddly does not seem to install the new file at all. Using Orca, I see that the file is in the file table, though, and its component is in the component table, FeatureComponent, MsiFileHash ... I did also have an additional thought. My original installer has a custom action to delete the same directory it ultimately creates as part of the installation. This is because this is going to be installing an application which was previously "xcopy installed" and needs to clean up first. The CA is as follows: <Binary Id="CasemanCurrentSurveyApplicationCA" SourceFile="C:\CasemanCurrentSurveyApplicationCA.CA.dll" /> <CustomAction Id="CA_CasemanCurrentSurveyApplicationCA" BinaryKey="CasemanCurrentSurveyApplicationCA" DllEntry="CleanDirectory" Execute="immediate" Return="check" /> <InstallExecuteSequence> <Custom Action="CA_CasemanCurrentSurveyApplicationCA" After="PublishProduct">NOT REMOVE</Custom> </InstallExecuteSequence> Does that run on the upgrade too (and I certainly hadn't intended it to, and the delete works ok with no trouble the first time)? I haven't been able to figure that out - the log doesn't show it, but ... Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 [email protected] Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada -----Original Message----- From: Peter Shirtcliffe [mailto:[email protected]] Sent: April-17-12 10:04 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] MSP question For one of the components with missing files, can you see any difference in the Wix source code between the original and updated versions ? They should be the same. Also, does your updated MSI upgrade an existing installation, without error, with the MSIENFORCEUPGRADECOMPONENTRULES property set to 1 ? I.e. msiexec /fvomus [path to updated .msi file] REINSTALL=ALL REINSTALLMODE=vomus MSIENFORCEUPGRADECOMPONENTRULES=1 -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: 17 April 2012 14:24 To: [email protected] Subject: Re: [WiX-users] MSP question Hi Peter, I only find one reference to the missing components: MSI (s) (18:04) [11:55:50:138]: Executing op: ComponentRegister(ComponentId={FEA74860-747D-4065-ABB8-7921CEE2BAF3},KeyPath= C:\cmsoft\60970\10021.Ver,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=0) MSI (s) (18:04) [11:55:50:140]: Executing op: ComponentRegister(ComponentId={027A9F27-B80E-4914-9C89-073012511CF3},KeyPath= C:\cmsoft\60970\SurvApp - Copy.INI,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=0) The first is a missing one, the second, seemingly identical in character, is one which survives. On the other hand, MSI (s) (18:04) [11:55:51:036]: Executing op: FileCopy(SourceName=qfix30zb.ini|SurvApp - Copy.INI,SourceCabKey=Fc3cde52e85bc4,DestName=SurvApp - Copy.INI,Attributes=4608,FileSize=131,PerTick=32768,,VerifyMedia=1,,,,,CheckC RC=0,,,InstallMode=58982400,HashOptions=0,HashPart1=-482575987,HashPart2=-268 032772,HashPart3=916218091,HashPart4=1544468535,,) MSI (s) (18:04) [11:55:51:037]: File: C:\cmsoft\60970\SurvApp - Copy.INI; To be installed; Won't patch; No existing file a reference of this sort exists for each of the files that survive. Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 [email protected] Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada -----Original Message----- From: Peter Shirtcliffe [mailto:[email protected]] Sent: April-17-12 4:41 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] MSP question What does a verbose log say about the disappearing components ? -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: 16 April 2012 17:59 To: [email protected] Subject: [WiX-users] MSP question Hi everyone, I'm using pyro to attempt to generate an .MSP file to use. In its .wxs, I have (for now) a single componentref which seems to work out ok, i.e. the patch successfully installs the additional file referenced by the new component. However, for some reason, the .MSP also as part of its operation removes some of the original files: not all of them and with seemingly no pattern. Each component "lost" a few files. All I can see is that the ones which did not survive the upgrade are ones flagged with a 512 attribute in the File Attributes column; the ones which made it are 4608 (i.e. 512+4096), which as far as I can tell is correct in this context. This prompts the question: what would create any difference between some files and others? My .wxs for the full MSI seems to contain all the files referenced properly. All files are keypath="yes" for what that's worth ... For example, under one directory: <Component Id="F38afa489ded74" Guid="fea74860-747d-4065-abb8-7921cee2baf3"> <File Id="F38afa489ded74" Source="c:\cmsoft\60970\10021.Ver" KeyPath="yes" /> </Component> <Component Id="Fc3cde52e85bc4" Guid="027a9f27-b80e-4914-9c89-073012511cf3"> <File Id="Fc3cde52e85bc4" Source="c:\cmsoft\60970\SurvApp - Copy.INI" KeyPath="yes" /> </Component> <Component Id="F55ff3f88e49d4" Guid="a38fc47d-8d1b-4a0e-91da-2b9e9becac10"> <File Id="F55ff3f88e49d4" Source="c:\cmsoft\60970\SURVAPP.exe" KeyPath="yes" Checksum="yes" /> </Component> <Component Id="F638bbbdf0bfd4" Guid="90e0f205-be97-419b-88f8-41a5bcc94be8"> <File Id="F638bbbdf0bfd4" Source="c:\cmsoft\60970\SurvApp.INI" KeyPath="yes" /> </Component> <Component Id="F647d809bd1b64" Guid="86717730-1a04-4bb5-8dfb-83b844da4167"> <File Id="F647d809bd1b64" Source="c:\cmsoft\60970\Vsconfig.mdb" KeyPath="yes" /> </Component> Only fileid="Fc3cde52e85bc4" made it. Even the number of "surviving" files is variable (it isn't as if it was only 1 or only the first few, etc.) The strange IDs, BTW, come from me generating this with an installerbuilder application I am working on to help automate installer package making for us. Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 [email protected] Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada ----------------------------------------------------------------------------- - For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ WiX-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. ----------------------------------------------------------------------------- - Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ WiX-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-users ----------------------------------------------------------------------------- - Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ WiX-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-users ----------------------------------------------------------------------------- - Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ WiX-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-users ----------------------------------------------------------------------------- - Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ WiX-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ WiX-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ WiX-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-users
