Note there are more things than the file date that change with every build
(namely the PackageCode). File date will not affect the file hash.
On Thu, Apr 11, 2013 at 8:47 AM, Spud wrote:
> I think I've been having a few blonde moments. (sigh)
>
> My build is re-creating this "static" msi file e
I ran into the same issue. Everytime the msi is built its check sum is
indeed different and the bundle stores this information. What you can do
is skip the msi build step unless it has actually changed and copy it the
desired location so that when the bundle builds it picks the same msi
everytime
I think I've been having a few blonde moments. (sigh)
My build is re-creating this "static" msi file each build, so that the file
date is changing. If I just build the thing and include the file as a static
resource instead then it *will* be the same hash value.
I need to get out more...
--
Vi
OK.
I should have known - rob was right all along (smile)
*Assuming* that WiX generates it's hash values the same way as the ms "File
Checksum Integrity Verifier"
(http://download.microsoft.com/download/c/f/4/cf454ae0-a4bb-4123-8333-a1b6737712f7/windows-kb841290-x86-enu.exe)
then the hash values o
Thanks Rob,
Yep, my MSI isn't changing. I don't seem to be able to determine why it
thinks the hash doesn't match.
If build 153 created the MSI, and builds 153, 154, 155 etc are looking at
the same DownLoadURL location (and presumably the same target hash values),
why do Bootstrappers 154 and 155
If the hash doesn't match then the Bundle expects a different MSI than the
one you are putting on the URL. You can't change the MSI without updating
the Bundle's that reference it.
The WiX toolset shares the ProjectAggregator.msi across many versions of
the Bundles because the ProjectAggregator.ms
I've changed my mind re separate question :)
Unless I'm understanding this incorrectly so long as it does not change, the
sharedcomponents.msi (which holds a number of third party dll's that will
not change) only needs to be in one place (i.e. the DownloadURL in the
MsiPackage element will not cha
Thanks Dave.
Luckily for us the items we want to store can reside in an unsecured folder,
so I don't need to jump through that hoop.
I'm getting failed installs due to hash match failures, but in the scheme of
things its probably best I create another topic. Thanks for your feedback :)
--
View
dysmi...@gmail.com]
Sent: 10 April 2013 12:10
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to create and reference a custom
pre-requisitepackage
Thanks Neil, I knew security would be an issue / can of worms, but at least I
can now stop looking for something that doesn't exist
9 matches
Mail list logo
