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 :)
--
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
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
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
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 of
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...
--
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
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 andysmi...@gmail.com wrote:
I think I've been having a few blonde moments. (sigh)
My build is re-creating this
The username and password could be stored encrypted in the bundle (when
passwords are supported or in a custom BA).
I've done this in MSIs / custom chainers before with custom actions, also for
persisting credentials in the registry.
Dave
-Original Message-
From: Spud
9 matches
Mail list logo
