Hello Yan and Blair, This is the same problem I have and also cannot seem to hurdle it. Here's the original post: http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg34336.htm l
After a lot of research and trial and error, I have given up trying to get this to work. I realize that I am probably doing something wrong somewhere, but have tried all combinations I could think of. I have resolved to this for my upgrades. 1. Only publish to add/remove programs on the initial install 2. Don't replace the product on upgrades and don't publish to add/remove programs 3. On upgrades, I have vbscript CA's that find/save the configuration files, then removes all files/folders from the website content. This allows the installer to "refresh" the website content with the new updates. I do a full replacement of all website content, including dll's in the bin directory for each upgrade. 4. Then I have another CA that restores the saved config files. This process works and the client can still uninstall fine. The problem is in add/remove programs, the version always remains at the original installed version. But, the client can get the version from our dll in the bin directory of the website. We deliver updates every quarter, so I just ran out of time to do this right. Hopefully in the future, I will resolve this. If so, I will be sure to share. If anyone knows how to hurdle this, I would love to see how. Thx! -----Original Message----- From: Yan Sklyarenko [mailto:y...@sitecore.net] Sent: Thursday, December 03, 2009 5:17 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] NeverOverwrite attribute behavior Thanks for the answer, Blair. However, I'm not sure I fully understand the way it works. The MSDN docs for Component table state the following: " ...the component remains enabled once installed even if the conditional statement in the Condition column later evaluates to False on a subsequent maintenance installation of the product... " This means that my component, which contains the IIS site definition to be created, will always be enabled (and thus, re-installed) on each maintenance installation, that is, patching as well. I can see the following entry in log file for this: Component: CreateIISSite7x64; Installed: Local; Request: Local; Action: Local Is this expected? I believe, yes. Then in order to avoid re-creating of IIS site on reinstall (upgrade), I have two options: - condition the appropriate component using installed state of component - condition the ConfigureIIs CA in order to prevent running it on upgrades Which one is preferable? Are there any other options? Thank you, -- Yan -----Original Message----- From: Blair [mailto:os...@live.com] Sent: Wednesday, December 02, 2009 19:02 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] NeverOverwrite attribute behavior MSDN explicitly says that the keypaths required for this flag are files and registry entries. When they are explicit they only guarantee the behavior within the scope they describe. Since you are using a directory as the keypath (and not a file) I assume the flag is being ignored, but you would have to look at a verbose debug log to be certain. The IIS extension simply checks the installation states of the component it lives inside of. It doesn't have anything to do with the keypath directly (that is Windows Installer's domain). You control the keypath (and thus the installation behavior of the IIS extension) yourself. -----Original Message----- From: Yan Sklyarenko [mailto:y...@sitecore.net] Sent: Wednesday, December 02, 2009 12:37 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] NeverOverwrite attribute behavior Hello WiX community, According to the MSI documentation, "if 'NeverOverwrite' bit is set, the installer does not install or reinstall the component if a key path file or a key path registry entry for the component already exists". What about components, which refer to the parent directory as a key path? For instance, I have a component containing only IIS site definition, and it doesn't specify any file or registry key as a key path. On reinstall, its key path, which is a parent directory, exists and hence it should behave as 'NeverOverwrite'. However, I still see my website being reinstalled, resetting the custom settings to initial defaults... Is this the way IIS extension works? Is it correct (I guess, no)? Or do I simply missing the point how 'NeverOverwrite' technique works? I would appreciate your hints. Thanks, -- Yan ------------------------------------------------------------------------ ---- -- 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 ------------------------------------------------------------------------------ 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
