Burn will use incorrect package if local

[wixbot]

If I have two versions of the same MSI file: an old version locally with the burn exe and one on our website. Burn exe will always call the old version which produces a hash error of course. It seems like burn is only going by the name and not checking the version of the MSI.

It should check the version of the MSI and if it is not correct do not use the local version, download the correct version.

Originally opened by wesman123 from http://sourceforge.net/p/wix/bugs/2967/

[wixbot]

Reading the local file for anything but copying is undesirable because the file may be on a network share. Such operations have a very high failure rate.

That said, there currently is no way a BA can override the selection of the local source. Changing that would be disruptive right now but we should investigate for next version.

[wixbot]

I'm not understanding you 100% (then again I don't know anything that is going on under the hood). When it processes the msi doesn't it have to check the product code and version to determine whether to install it or not? How about if there is a newer version of the msi that's already installed? Or is burn that smart?

Just to be clear: I have a downloadUrl attribute in burn for my MSI which is called Shellsetup.msi (my msi that installs my application). It works fine when the burn exe is in a folder by itself (it downloads the msi from the url) but if I put an old version of the Shellsetup.msi in the same folder as my bundle exe it always tries to install that msi. It looks like it only goes by the file name only to determine if its the correct msi.

So I'm not sure where a network share comes into play. Even if it does once the local file is copied can't you inspect it's version then? If its not correct try the download url or fail.

Just wanted to make sure I was understood correctly.

[wixbot]

Updating title to better reflect the root issue.

[wixbot]

Originally changed by barnson
Release changed from v3.8 to v3.x

[wixbot]

Originally changed by heaths
AssignedTo set to heaths

[wixbot]

Fixed for wix3: wixtoolset/wix3@cad7bf5

Need to port for wix4.

Originally posted by heaths

[wixbot]

Fixed in wix4: wixtoolset/wix@466ac87

Originally posted by heaths
Resolution set to fixed
Status changed from Open to Resolved

[wixbot]

Incorrectly resolved. Not fixed by previous commits.

Originally posted by robmen
Resolution changed from fixed to
Statuschanged fromResolvedtoOpen

[wixbot]

Not that it matters but I was the one who created this bug report.

Originally posted by wesman

[wixbot]

We had an email conversation and discussion in triage about this and it requires further investigation. I did solve this problem internally (it was related to the original commits, but when migrating it to OSS I mixed the two related issues) but in a manner Rob didn't want (and it did cause perf issues): by checking the hash of the layout file. On a network, this was very slow (we took said code out), but that means that the hash is eventually verified only after the BA is given a chance to resolve source. Rob said he was going to think about how to proceed. IMO, the BA source resolution code needs to happen later, or the BA be given a second chance at resolving.

Originally posted by heaths
Status changed from Open to Untriaged

[wixbot]

From a related email conversation on this bug, there's basically two aspects to this bug:

1. Give the BA a chance to resolve source after verification failures (i.e. wrong payload), and
2. Verify that the payload is the correct payload and not nearly signed by the same publisher.

Originally posted by heaths

[rseanhall]

I'm not sure how practical this is, but in v3.x a BA could call IBootstrapperEngine::SetLocalSource for every payload before calling Apply. It would set it to an absolute path that didn't exist in order to get the engine to skip the probing of local paths during the payload's acquisition, causing an OnResolveSource event. Due to the complex caching logic in the engine, the BA might have to request a retry during the right events to make every payload go through acquisition.