[wix-users] Controlling Updates of unversioned files

Nir Bar nir.bar at panel-sw.com
Tue Mar 9 04:53:05 PST 2021


You can use my WiX extension https://www.nuget.org/packages/PanelSwWixExtension/


<File ...>
<panelsw:ForceVersion/>
</File>

--

Nir Bar

WiX Expert






---- On Mon, 08 Mar 2021 22:50:57 +0200 Edwin Castro via wix-users <mailto:wix-users at lists.wixtoolset.org> wrote ----


Alternatively, install BYZ.p8z in a component that uses a different
versioned file as the KeyPath. In this case, BYZ.p8z will be updated
whenever the versioned file is updated, even if BYZ.p8z has changed.

--
Edwin G. Castro


On Mon, Mar 8, 2021 at 10:51 AM Rob Mensching via wix-users <
mailto:wix-users at lists.wixtoolset.org> wrote:

> Maybe: https://docs.microsoft.com/en-us/windows/win32/msi/reinstallmode
>
>
> ---
> Short replies here. Complete answers here:
> https://www.firegiant.com/services/
>
> -----Original Message-----
> From: wix-users <mailto:wix-users-bounces at lists.wixtoolset.org> On Behalf Of
> Todd Hoatson via wix-users
> Sent: Monday, March 8, 2021 8:41 AM
> To: WiX Toolset Users Mailing List <mailto:wix-users at lists.wixtoolset.org>
> Cc: Todd Hoatson <mailto:todd.hoatson at gmail.com>
> Subject: [wix-users] Controlling Updates of unversioned files
>
> jhg7We have run into a problem with some files that have been updated, but
> they don't get installed on some users' systems.
>
> The files in question are not versioned.  We have some text files that we
> install, as well as some zip files.  Our current problem is with the latter.
>
> One oddity with the Windows file system is seen when I copy a file
> manually:  One copy of the BYZ.p8z file has a Created date of 1/8/2019 and
> a Modified date of 7/24/2020.  When I copy it to a new folder, the Modified
> date of the copy is the same, but the Created date is 3/5/2021 even though
> this does not match the Created date of the original file, nor is it
> today's date.
>
> This makes it difficult to control my test scenario...
>
> So, with this file (BYZ.p8z) copied to the install location on my system,
> I attempt to install a new version of the product.  This installation
> successuflly updates the BYZ.p8z file to have Created date 3/5/2021 and
> Modified date is the same.
>
> I start over, copying the BYZ.p8z file to the installation location.  This
> time the file after copying has a Created date of 1/8/2019 and a Modified
> date of 7/24/2020.  (This is to reproduce the situation on some users'
> systems where the file has a Modified date later than the Created date.
> It's not yet clear how this situation came about.)
>
> Using the Windows Apps and Features tool, I choose to Modify the
> installation in order to update the back-level file I just copied.  When
> the installer starts, I click on Repair.  But the back-level file is not
> updated!  Only if I delete the BYZ.p8z file from the install location will
> repair copy the correct file.
>
> After a bit of research, we found the information on File Versioning Rules
> - Win32 apps | Microsoft Docs
> <https://docs.microsoft.com/en-us/windows/win32/msi/file-versioning-rules
> >,
> where I read:
>
> "Nonversioned Files are User Data—If the Modified date is later than the
> Create date for the file on the computer, do not install the file because
> user customizations would be deleted. If the Modified and Create dates are
> the same, install the file. If the Create date is later than the Modified
> date, the file is considered unmodified, install the file."
>
> It seems to be a faulty assumption that Nonversioned Files are User Data,
> as this severely limits the kinds of files that can be used for app data.
> But this is the situation with the Windows installer, which we have to
> live with.
>
> I tried to change/override this behavior by setting the KeyPath attribute
> for the file to 'no'.  Since we use heat to harvest the files for the
> installation, I did this by using an xslt transform, containing the
> following lines:
>
> <!-- Specifically, special handling for BYZ.p8z File element -
>     <xsl:template match="wix:File[contains(@Source, 'BYZ.p8z')]">
>         <!-- Just copy the tag itself -->
>         <xsl:copy>
>             <!-- Generally, copy all attributes -->
>             <xsl:apply-templates select="@*" />
>
>             <!-- Modify the KeyPath attribute to 'No' to turn off version
> checking -->
>             <xsl:attribute name="KeyPath">no</xsl:attribute>
>
>             <!-- Now take the rest of the inner tag -->
>             <xsl:apply-templates select="node()" />
>         </xsl:copy>
>     </xsl:template>
>
> I checked the .wxs file output by heat and confirmed that the BYZ.p8z file
> has KeyPath="no" and Permanent="yes".  Yet when I look at the log file
> produced when the installer failed to update the file, I see:
>
>
> FileCopy(SourceName=BYZ.p8z,SourceCabKey=BYZ.p8z,DestName=BYZ.p8z,Attributes=512,FileSize=3643291,PerTick=65536,,VerifyMedia=1,,,,,CheckCRC=0,,,InstallMode=58982400,HashOptions=0,HashPart1=-1495337071,HashPart2=-1750950674,HashPart3=1121107855,HashPart4=-1691272291,,)
> MSI (s) (B4:90) [15:53:41:311]: File: C:\My Paratext 9
> Projects\_Resources\BYZ.p8z; Won't Overwrite; Won't patch; Existing file is
> unversioned but modified
>
> Is there any way for us to override this behavior?
>
> thanks,
> Todd Hoatson
> Mobile: 763-291-3312
> Email: mailto:todd.hoatson at gmail.com
> http://www.linkedin.com/in/toddhoatson
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/
>
> ____________________________________________________________________
> WiX Toolset Users Mailing List provided by FireGiant
> http://www.firegiant.com/

____________________________________________________________________
WiX Toolset Users Mailing List provided by FireGiant http://www.firegiant.com/


More information about the wix-users mailing list