Regarding "I've tried scripting the installer to remove the file in question first before writing the new one in, but only the file remove is running the first time the installer is run. If the installer is run a second time, the file remove does not run (because the file isn't there and the file is then written as expected)."
The concept you'll want to look up here is "transitive components". Reference: http://msdn.microsoft.com/en-us/library/aa372462(VS.85).aspx -----Original Message----- From: John Nannenga Sent: Thursday, November 05, 2009 5:00 PM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] 'downgrading' a file during an upgrade This might get the job done for you... <Component Id="Foo.exe" Guid="Guid1"> <File Id="Foo.exe" Name="Foo.exe" Source="c:\Foo.exe" Checksum="yes" KeyPath="yes" Vital="yes"/> </Component> <Component Id="R_Foo.exe" Guid="Guid2" Transitive="yes"> <RemoveFile Id="R_Foo.exe" Name="Foo.exe" On="install"/> <Condition>?Foo.exe=3 AND NOT PATCH</Condition> </Component> This would work if your upgrade process will install missing files. -----Original Message----- From: Blair [mailto:os...@live.com] Sent: Thursday, November 05, 2009 10:40 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] 'downgrading' a file during an upgrade Except for the fact that both components are "touching" the same file there is no relationship in Windows Installer's view-of-the-world between those two components apart from being in the same directory (they don't share a keyfile) so there is no way for it to know that the one component will cause the other to need to be "restored", so that kind of dance won't work within a single transaction. The component states are evaluated before any changes occur to the box, and are not reevaluated again once the script starts being built. If the builds with the incorrect file version are all "in-house" you could try blocking installation when those builds are present and forcing a manual removal before installation. That would probably be the easiest. The next easiest would be to move to 4.x.x.x or something like that for your version numbers (at least for that file). You could try setting REINSTALLMODE but that affects the entire transaction, not just that file, so it could have other consequences you may not be able to mitigate. -----Original Message----- From: Plowman, Mark [mailto:mark.plow...@n4s.co.uk] Sent: Thursday, November 05, 2009 2:51 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] 'downgrading' a file during an upgrade Apologies if this arrives twice. The first one got bounced. Hoping someone can help me with this. We've got a scenario where we've discovered a dll that has a rogue version number that is much higher than the rest of the system (due to a missed assemblyinfo file) . The system itself is still in development so we want to bring the version number back into line with the rest of the system. We've corrected the version number but we are currently running in upgrade mode for our releases. Initially the file failed to update due to the version number of the original file being higher than the new file. I've tried scripting the installer to remove the file in question first before writing the new one in, but only the file remove is running the first time the installer is run. If the installer is run a second time, the file remove does not run (because the file isn't there and the file is then written as expected). I suspect this is happening because the installer is deciding what it can and can't do up front and is not taking the file removal into account when it compares version numbers. Am I correct in this assumption? Second (and most important question) - is there a way around this without performing an uninstall? Ideally, I'd like to be able to tell the installer allow downgrading just for this one file but I haven't found a way of doing that yet. Anyone have any ideas please? The incorrect version number is 3.5.0.xxxx The correct version number is 1.4.2007.xxxx Below are excerpts from install logs and the wxs file so you can see what is happening. Log: MSI (s) (C8:E4) [16:08:58:636]: Component: RemoveApp_Code.dll; Installed: Absent; Request: Local; Action: Local MSI (s) (C8:E4) [16:08:58:636]: Component: App_Code.dll; Installed: Absent; Request: Local; Action: Null Here you can see that no action has been set for adding the file back in. Wxs script <Component Id="RemoveApp_Code.dll" Guid="F93BA901-78D4-4858-8505-FF008B35AEBC"> <RemoveFile Id="RemoveApp_Code.dll" Name="App_Code.dll" On="install" /> </Component> <Component Id="App_Code.dll" Guid="8161FCBB-85F1-4287-9AF2-E014100D6ED2"> <File Id="App_Code.dll" Name="App_Code.dll" Source="$(var.SrcWebsite)\bin\App_Code.dll"/> </Component> .... <ComponentRef Id="RemoveApp_Code.dll"/> <ComponentRef Id="App_Code.dll"/> We know that this method of removing and adding works as we have done the same thing for the web.config file with no problems. Of course, this is not a versioned file which probably explains why it works when it doesn't for the versioned file. Any suggestions gratefully received. Cheers, Mark This e-mail has come from Experian, the only business to have been twice named the UK's 'Business of the Year’ =================================================================================== Information in this e-mail and any attachments is confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other binding commitment through the use of this electronic communication unless it is issued in accordance with the Experian Limited standard terms and conditions of purchase or other express written agreement between Experian Limited and the recipient. Although Experian has taken reasonable steps to ensure that this communication and any attachments are free from computer virus, you are advised to take your own steps to ensure that they are actually virus free. Companies Act information: Registered name: Experian Limited Registered office: Landmark House, Experian Way, NG2 Business Park, Nottingham, NG80 1ZZ, United Kingdom Place of registration: England and Wales Registered number: 653331 ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
