2
votes

I am using heat to harvest the binaries from a .csproj file. This works fine, however, when I uninstall or upgrade the application, I want to leave the harvested file, "MyApp".exe.config in the install directory so users don't lose their default settings. Do I need to apply a specialized XSLT Transform along with the heat command? Or since the result of the harvest is just a couple of components in a fragment,maybe it would be better to just manually add the files so I could have control of each one individually? I am new to WiX and having a little trouble finding the answer to this.

Thanks for any suggestions!

3
Could you elaborate on "user s ... default settings"? Are you using the .NET 2.0 and later application settings classes? Are you talking "Application" settings, "User" settings or both? Are you generating them using the Visual Studio C# or VB.NET Settings designer? As you may know, if a User setting is changed for an individual user, the current value is not stored in "MyApp".exe.config.Tom Blodget
Hi Tom, thanks for your reply. This is a .Net 2.0 C# Application, it is using the settings designer, and all of the settings in the .exe.config file are userSettings. It appears I misunderstood the role of the .exe.config file. The msdn link helped clear it up a bit. It says "the settings architecture will create the user.config files on demand the first time the application saves settings for that user." It appears that I don't need to be concerned about "MyApp".exe.config being overwritten or uninstalled. Is this correct?clintsmith

3 Answers

3
votes

If you save the following to a file called e.g. transform.xslt and add -t transform.xslt to the commandline for heat, the heat-results should be transformed and will add the Permanent-attribute to MyApp.exe.config:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
    xmlns:wix="http://schemas.microsoft.com/wix/2006/wi"
    xmlns="http://schemas.microsoft.com/wix/2006/wi"
    exclude-result-prefixes="wix">

    <xsl:template match="wix:Wix">
      <xsl:copy>
        <xsl:apply-templates select="@*" />
        <xsl:apply-templates />
      </xsl:copy>
    </xsl:template>

    <xsl:template match="wix:Component">

        <!-- Just copy the tag itself -->
        <xsl:copy>
            <!-- Copy all attributes -->
            <xsl:apply-templates select="@*" />

            <!-- Here comes the distinction: if you find our special component, do some special things -->
            <xsl:choose>
                <!-- Note that the string is translated to all lower case, so you don't have to care about being case sensitive or not -->
                <xsl:when test="translate(@Id,'ABCDEFGHIJKLMNOPQRSTUVWXYZ','abcdefghijklmnopqrstuvwxyz') = 'myapp.exe.config'">
                    <!-- Here we will add the Permanent-attribute to this very special component -->
                    <xsl:attribute name="Permanent">yes</xsl:attribute>
                </xsl:when>
            </xsl:choose>

            <!-- Now take the rest of the inner tag -->
            <xsl:apply-templates select="node()" />
        </xsl:copy>

    </xsl:template>

    <xsl:template match="@*|node()">
      <xsl:copy>
        <xsl:apply-templates select="@*|node()" />
      </xsl:copy>
    </xsl:template>

</xsl:stylesheet>

The Permanent-attribute, according to the WiX help file, does the following: If this attribute is set to 'yes', the installer does not remove the component during an uninstall. The installer registers an extra system client for the component in the Windows Installer registry settings (which basically just means that at least one product is always referencing this component). Note that this option differs from the behavior of not setting a guid because although the component is permanent, it is still patchable (because Windows Installer still tracks it), it's just not uninstallable.

Note that I've added a translate to lower case for the file-name, so instead of checking for MyApp.exe.config add all in lower case 'myapp.exe.config'. This way you don't have to deal with lower / upper case problems. Also note that I assume that you use the -suid-option for heat, i.e. instead of creating Ids with random letters / digits for every component, every component normally gets its file-name as Id.

1
votes

If you do a major upgrade and have RemoveExistingProducts at the end the upgrade follows file overwrite rules, which include not replacing a user modified file.

On uninstall it will still be removed, but if the product is uninstalled why would anyone need the config file for the uninstalled app?

0
votes

It appears I misunderstood the role of the .exe.config file. This msdn link helped clear it up a bit. It says "the settings architecture will create the user.config files on demand the first time the application saves settings for that user." It appears that I don't need to be concerned about "MyApp".exe.config being overwritten or uninstalled. Thanks to Tom for pointing me in the right direction!