16k
commented
8 years ago The Problems
For problem 1 you could either use the pre-start script to run the vcredist install or run a full install which just does an update. If you decide to just run the vcredist install, I highly recommend not running the bare vcredist installer, Wrap it in a WiX burn bundle that will check pre-requisites and repair broken installs.
Furthermore if you go with WiX and do not want to download a full install each time you can do a bit of work to download minor updates that only include patches. It requires a bit of work upfront and if we do it we can share the load between PMS and PMP.
Problem 2, I find this problem weird and is not what a user on windows might expect. With PMS if you try to install a newer version it'll do an upgrade, if you run the same installer again it will prompt for repair or uninstall.
Problem 3, Registry updates are MSI and WiX's bread and butter.
Problem 4, This is just hard to implement in windows, possibly a happy median is to use patch msi install files that only contain changes. Auto update gets the patches, users download the installs. Patch msis can target multiple versions at the expense of file size, when the patch msi gets too big, just start a new one for the next range of versions.
WiX code: We can easily split up the WiX code and share it between our two projects, we can reuse most of the wix files, they're not complicated. The difficulty in using them is just understanding the whole windows (MSI) way of doing things
The Pain
Hopefully I've suffered the pain and learned some lessons so you won't have to.
vcredist
The 2015 visual studio redist consists of two parts, one part belongs to visual studio and it is controlled in the normal way redists of old were handled. The other part is now part of the operating, it is sometimes referred to as the "Universal CRT". It is an OS patch and is serviced by Windows itself. The vast majority of the problems we have had with the vcredist has been getting this patch installed. The vcredist didn't check for the OS prerequisites properand would install the normal redist part but not the patch leaving a broken redist on a user's computer. Windows 10 is not affected by this problem because it already has the Universal CRT included.
In the PMS install we now detect the vcredist prerequisites and warn the usser first of all, we also detect and repair broken vcredist installs (messed up installs could be from old pms or even other apps and manual vcredist installs that don't prerequisite properly) and repair it. Reports on vcredist problems have dried up significantly since we implemented this.
Poor reboot handling
Another thing that bit me was our poor reboot handling. I screwed up when I used "/promptrestart /passive" options when starting the installer in earlier versions of the pms install. /promptrestart only works on a fuller UI than the /passive UI, so a silent restart can occur.
The solution was to use /passive /noreboot, which will delay reboot even if required, I tested this scenario and it seems to work fine even with other apps using the vcredist (they just use temporary renamed files till the user is reminded to reboot the computer). The user will be prompted to reboot sometime in the future when they next try to install something.
Since becoming aware of the problem I have minimised it by making sure newer installs shut down pms and related processes before installing the new vcredist. I've removed /passive from our current releases to be extra safe.
I'm currently working on a modified installer for our next release that won't reboot even if "/noreboot" is NOT used. This is to handle being called by the old code when users are updating from old versions.
tru
This is a random brain dump of a ticket where I document the problems we have with the current windows installer package.
1) When we update the redist package the installer for that needs to be executed again. This should not happen that often but it will happen and currently it's a problem because we have to turn off auto-update for windows when it happens. 2) The current installer doesn't allow for running a newer version of the installer and installing "over" what you have installed already. 3) Auto-update doesn't update the registry correctly so the version and the files in there are not tracked correctly 4) auto-update doesn't work with delta updates. there are so many problems with file-locking and stuff like that which needs much more careful code.
We have a couple of different solutions here:
For problem 1 we can:
For problem 2 we can:
For problem 3 we can:
For problem 4 we can:
I think this might tie into what we want to do with PMS in the future in terms of installers as well. But it seems clear to me that the safe thing to do is to switch to something like WiX and adopt the PMS model for updating and look forward to a future where we can iterate on our auto-update framework and do it even better.
The question is if we can adopt WiX without seven layers of pain as we have seen in PMS?
Paging for opinions by @16k @stsimmons that has been working with these things the most.