WiX, how to prevent files from uninstalling though we forgot to set Permanent="yes"

Question

We have a product installer created with Wix, containing a program package ("V1") and some configuration files. Now, we are going to make a major upgrade with a new product code, where the old version of the product is uninstalled and "V2" is installed. What we want is to save one of the configuration files from uninstalling, since it is needed for the V2, too. Unfortunately, we forgot to set the Permanent="yes" option when we delivered V1 (read this question for more information).

Here comes the question: is there an easy way of preventing the uninstall of the file anyhow? Of course, we could add a custom action to the script to backup the file before uninstallation, and another custom action to restore it afterwards, but IMHO that seems to be overkill for this task, and might interfere with other parts of the MSI registration process.

EDIT: And yes, the NeverOverwrite="yes" attribute is already set in V2, and the behaviour is as I described it.

I don't think it will help to change something directly in the component parameters of V2. Perhaps there's a chance to modify the registry somehow in a custom action before uninstalling V1 so the installer service thinks the configuration file in V1 was installed with Permanent="yes"?

Cant you just reinstall those files, or is it that you want to keep the local file because they may have been modifed? — Charles Gargent, May 12 '10 at 08:06
That's exactly the case - the configuration file might have been modified and should be kept as it is. — Doc Brown, May 12 '10 at 08:48

score 6 · Accepted Answer · edited Aug 10 '16 at 11:18

Try the NeverOverwrite attribute for the configuration file

If this attribute is set to 'yes', 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.

EDIT

I have just tested this in a test setup. At first it didn't work because I had scheduled the RemoveExistingProducts action before InstallInitialize sequence. This removes the old product before the new product is installed so it can't compare.

However when I set it to after InstallFinalize it did work, it left the file there even though the original setup didn't have NeverOverwrite set. here are my two test examples

version 1.0.0.0

<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Product Id="35d07bf8-a729-402d-83d6-fdc55799a3d5" Language="1033" Manufacturer="..." Name="test1" UpgradeCode="9773a278-068d-4fac-8241-4a5b7e54f15a" Version="1.0.0.0">
        <Package Compressed="no" InstallerVersion="200" />
        <Property Id="ALLUSERS" Value="1" />
        <Upgrade Id="9773a278-068d-4fac-8241-4a5b7e54f15a">
            <UpgradeVersion OnlyDetect="no" Property="REMOVEOLDVERSION" Maximum="1.0.0.0" IncludeMaximum="no" />
            <UpgradeVersion OnlyDetect="yes" Property="NEWERFOUND" Minimum="1.0.0.0" IncludeMinimum="no" />
        </Upgrade>
        <Directory Id="TARGETDIR" Name="SourceDir">
            <Directory Id="ProgramFilesFolder" Name="ProgramFilesFolder">
                <Directory Id="INSTALLDIR" Name="test1">
                    <Component Id="New_Text_Document.txt" Guid="{CCA38D83-A890-4528-B11D-DA2E2DCDED93}" Feature="ProductFeature">
                        <File Id="New_Text_Document.txt" KeyPath="yes" Source="Harvest\ProgramFilesFolder\INSTALLDIR\New Text Document.txt" />
                    </Component>
                </Directory>
            </Directory>
        </Directory>
        <Feature Id="ProductFeature" Level="1" Title="CompletePackage" Description="The complete Product." Display="expand" />
        <CustomAction Id="NewerFound" Error="A later version of [ProductName] is already installed" />
        <InstallExecuteSequence>
            <Custom Action="NewerFound" After="FindRelatedProducts">NEWERFOUND</Custom>
            <RemoveExistingProducts After="InstallFinalize" />
        </InstallExecuteSequence>
        <UIRef Id="WixUI_Minimal" />
        <Media Id="1" />
        <UI />
    </Product>
</Wix>

version 1.0.1.0

<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
    <Product Id="1da36626-d760-4c4c-8a5c-3eb3841dbfd5" Language="1033" Manufacturer="..." Name="test1" UpgradeCode="9773a278-068d-4fac-8241-4a5b7e54f15a" Version="1.0.1.0">
        <Package Compressed="no" InstallerVersion="200" />
        <Property Id="ALLUSERS" Value="1" />
        <Upgrade Id="9773a278-068d-4fac-8241-4a5b7e54f15a">
            <UpgradeVersion OnlyDetect="no" Property="REMOVEOLDVERSION" Maximum="1.0.1.0" IncludeMaximum="no" />
            <UpgradeVersion OnlyDetect="yes" Property="NEWERFOUND" Minimum="1.0.1.0" IncludeMinimum="no" />
        </Upgrade>
        <Directory Id="TARGETDIR" Name="SourceDir">
            <Directory Id="ProgramFilesFolder" Name="ProgramFilesFolder">
                <Directory Id="INSTALLDIR" Name="test1">
                    <Component Id="New_Text_Document.txt" Guid="{CCA38D83-A890-4528-B11D-DA2E2DCDED93}" Feature="ProductFeature" NeverOverwrite="yes">
                        <File Id="New_Text_Document.txt" KeyPath="yes" Source="Harvest\ProgramFilesFolder\INSTALLDIR\New Text Document.txt" />
                    </Component>
                </Directory>
            </Directory>
        </Directory>
        <Feature Id="ProductFeature" Level="1" Title="CompletePackage" Description="The complete Product." Display="expand" />
        <CustomAction Id="NewerFound" Error="A later version of [ProductName] is already installed" />
        <InstallExecuteSequence>
            <Custom Action="NewerFound" After="FindRelatedProducts">
NEWERFOUND</Custom>
            <RemoveExistingProducts After="InstallFinalize" />
        </InstallExecuteSequence>
        <UIRef Id="WixUI_Minimal" />
        <Media Id="1" />
        <UI />
    </Product>
</Wix>

It may not work if you have the RemoveExistingProducts in the wrong order — Charles Gargent, May 12 '10 at 14:25
No, that does not seem to work, too (we had already ) in V1 and V2. Are you sure you used a clean environment for your tests, i.e. a virtual machine? — Doc Brown, May 12 '10 at 16:27
I am using version 3.5, what version are you using? It shouldnt make a difference, but it might! Also if you compile both those examples install the first then the second the file doesnt get replaced. Are any of these files that are being replaced in a per user component? — Charles Gargent, May 12 '10 at 18:52
I set up two test projects for your examples, and they are working as you said (with WiX 3.0). Nevertheless, in the setup for our own product, setting NeverOverwrite does not help. Seems I have to work out the difference between your example and ours. — Doc Brown, May 13 '10 at 12:58
Did you find a complete solution for this? I have a similar problem and I am getting different results. When I run the installer with RemoveExistingProducts After="InstallFinalize" the files are there right until the end of the installation and all of a sudden it decides to run the RemoveExistingProducts action a second time, thus now removing the old files... did you encounter this problem? — Kezza, Aug 28 '13 at 14:12
Having the same - it just runs the old installer in uninstall mode and wipes all the files, even ones with NeverOverwrite flag. — berkus, Dec 10 '15 at 16:29

score 0 · Answer 2 · answered Jan 28 '13 at 10:08

0

The way I am fixing this is very simple. I don't install yourapp.config files but only yourapp.config.new On the first run the application before doing anything else check for the config file. If there is none make a copy yourapp.config.new to yourapp.config

This is very simple it doesn't use any special attributes. When the application is uninstalled the config file is not uninstalled. When the application is re-installed file is disturbed. Note that when the application is repaired the config is not modified either.

answered Jan 28 '13 at 10:08

Pascal Ganaye

1,174
12
28

Well, your answer misses two points of the question. First, the question is about an already deployed system. Letting the installer remove the config file (even when the application V2.0 could create a new one) throws away any information an admin has entered manually there, which is what I wanted to avoid. Second, I was talking about a config file which lives in the `Program` directory, where in most enterprise environments you need administrative access rights to write anything there, which the installer has, but not a "normal" program. – Doc Brown Jan 29 '13 at 15:17

WiX, how to prevent files from uninstalling though we forgot to set Permanent="yes"

2 Answers2

Linked