I wasn't super comfortable with the changes to msiexec before and I think that I understand the issues better now. Our release automation was creating MSIs with identical ProductCodes and PackageCodes, which is forbidden for the PackageCode field and carries some semantic implications for the ProductCode. In principle things are more auto-update-friendly if you have continuity in the ProductCode, but it looks like we should change it with every release. That way, the msiexec /i works (while still maintaining some sense of continuity because the packages keep the same UpgradeCode), and we don't run into problems with the installation "source": the upgrades were failing because the installer wants the upgrade package to have been downloaded to the same directory as the package that was used to make the initial install (!!). The docs also say that you can't rename the MSI file within the same ProductCode (!!!), which I want to do for traceability.
Anyway, the newest version of Cranko (0.10.2) will now update these codes when it's setting up for a release, so we can go back to the previous msiexec invocation. I'm also adding arguments to save a log file in the tempdir since that could come in handy for debugging.
This does mean that the auto-update process is not quite as smooth as it could be and re-prompts the user for things like the install location. I believe that's the same behavior we've always had, though.
I wasn't super comfortable with the changes to
msiexecbefore and I think that I understand the issues better now. Our release automation was creating MSIs with identical ProductCodes and PackageCodes, which is forbidden for the PackageCode field and carries some semantic implications for the ProductCode. In principle things are more auto-update-friendly if you have continuity in the ProductCode, but it looks like we should change it with every release. That way, themsiexec /iworks (while still maintaining some sense of continuity because the packages keep the same UpgradeCode), and we don't run into problems with the installation "source": the upgrades were failing because the installer wants the upgrade package to have been downloaded to the same directory as the package that was used to make the initial install (!!). The docs also say that you can't rename the MSI file within the same ProductCode (!!!), which I want to do for traceability.Anyway, the newest version of Cranko (0.10.2) will now update these codes when it's setting up for a release, so we can go back to the previous
msiexecinvocation. I'm also adding arguments to save a log file in the tempdir since that could come in handy for debugging.This does mean that the auto-update process is not quite as smooth as it could be and re-prompts the user for things like the install location. I believe that's the same behavior we've always had, though.