Use WiX 5 #66
Merged
Use WiX 5 #66
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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-wix-5
branch
2 times, most recently
from
55f8095 to
949b668
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.
This is a preview. It appears to build a working x64 installer; I have tested nothing else yet.
Also, put blame where it belongs, which is Windows Installer. If this was a bug in WiX, then the fix would be to enforce 8.3 file names for ODBC drivers, and we wouldn't like that very much either, would we?
- Remove most Component elements in favor of naked files - Replace PGFOLDER variable with ProgramFiles6432Folder The Condition element on Component has become an attribute in WiX 5, and the combination of preprocessor and component condition (i.e. include a non-x64 condition only in a non-x64 package) to install PGXA only from a package native to the underlying OS does not work anymore. Replace it with a pure component condition that includes the package architecture. The Template summary property has this information already, but it is not available from within the installation, and I'm not about to start writing custom actions.
|
I don't think there is more that needs to be done here this side of adding the arm64 package. |
|
I just have to now figure out why it fails |
|
Thanks so much for this! |
I saw that. Have another commit. |
|
cool, thanks so much |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This branches from my other MSI branch. x64 and x86 build and work.
See the README for how to install what bits of WiX are needed.
WiX 5 does not use the file name in the key of the File table by default; I have changed modify_msi.vbs to identify its target files by the component ID instead ... and most recently by the file name itself.