MSI improvements #64
MSI improvements #64
Conversation
chrullrich
force-pushed
the
msi-improvements
branch
2 times, most recently
from
e71947d to
8268ecb
Compare
|
My exploration of both the PostgreSQL and psqlODBC build systems has not been overly successful (and it certainly did not help that PostgreSQL switched to Meson on Windows). I am able to build PostgreSQL in the most basic way, with essentially no optional features at all. The [censored] [censored] buildInstallers.ps1 ... [censored]. I managed to at least get it to pick up OpenSSL and could see it in libpq's dependencies, but the OpenSSL libraries did not show up in the PostgreSQL installation directory. psqlODBC installers include only those dependencies of libpq that are found in the same directory as libpq.dll, so I ended up with a package that installed a libpq with unresolved dependencies. I have no idea if I'm supposed to copy libssl-3.dll and libcrypto-3.dll manually; instead, I disabled the OpenSSL support again. Any advice on how this is meant to work will be greatly appreciated. |
chrullrich
force-pushed
the
msi-improvements
branch
from
3076228 to
23ded76
Compare
|
@chrullrich I'm going to take any help I can to get the installer working properly so whatever support you need, just ask. |
|
Also ideally we switch to WIX4 as I would like to be able to release on windows ARM but it doesn't support WIX3 |
|
Thanks for the link. It looks like it will be helpful. Do you specifically need WiX 4, or will 5 also work? |
I think 5 will work as well, I guess there's no reason not to go to 5 |
Instead of externally generating it and using it explicitly.
This prevents upgrades from leaving files from the previous version behind that are not in the new version.
Use the ODBCDriver element only, without additional Registry settings. This works, although it does not solve the file name issue and therefore still requires removing the short file names from the File table. It also works for installing the x86 driver on an x64 system. Whether it works on an x86 system remains unknown.
Tested on Windows 10 x86; the driver installs correctly and works at first glance (in Access, to be precise). Registry and file system look good. The comment saying it "probably would be safe" is probably correct.
This element compiles into approximately the same entries in the Upgrade, CustomAction, and InstallExecuteSequence tables.
I think this was the product code, a long time ago.
By about 20 percent.
chrullrich
force-pushed
the
msi-improvements
branch
from
23ded76 to
f3541e2
Compare
Use the FileName column itself instead of the file ID. This is less susceptible to changes in file IDs (and component IDs) that may happen when relying more on default behaviors in future WiX versions.
chrullrich
force-pushed
the
msi-improvements
branch
from
d8b782c to
77b1205
Compare
|
You know what? Have at it! :-) |
|
Obsoleted by #66. |
This is the yield from ~8 hours of poring over the code. This is mostly janitorial stuff, but I'm by no means done; there is more to come. It would be great if you could look it over and tell me whether you are comfortable with it.
My claim in #57 that the component rules violation was the reason for the installation path not changing between versions was wrong. This is in fact an intentional behavior of Windows Installer as long as ODBC drivers are installed using the built-in support, i.e. the ODBCDriver table. In that case, the SetODBCFolders standard action overrides the installation path to maintain the driver in the same location.