Instead of externally generating it and using it explicitly.

This prevents upgrades from leaving files from the previous versionbehind 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 thereforestill requires removing the short file names from the File table.It also works for installing the x86 driver on an x64 system. Whether itworks on an x86 system remains unknown.

Tested on Windows 10 x86; the driver installs correctly and worksat first glance (in Access, to be precise). Registry and file systemlook good.The comment saying it "probably would be safe" is probably correct.

According to docs, using Package/@platform "is discouraged". The -archoption also provides the default bitness for components, making theComponent/@win64 attribute unnecessary in single-architecture packages.

This element compiles into approximately the same entries in theUpgrade, CustomAction, and InstallExecuteSequence tables.

I think this was the product code, a long time ago.

By about 20 percent.

Use the FileName column itself instead of the file ID. This is lesssusceptible to changes in file IDs (and component IDs) that may happenwhen relying more on default behaviors in future WiX versions.

This is a preview. It appears to build a working x64 installer; I havetested nothing else yet.

Also, put blame where it belongs, which is Windows Installer. If thiswas a bug in WiX, then the fix would be to enforce 8.3 file names forODBC 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 ProgramFiles6432FolderThe Condition element on Component has become an attribute in WiX 5, andthe combination of preprocessor and component condition (i.e. includea non-x64 condition only in a non-x64 package) to install PGXA only froma package native to the underlying OS does not work anymore. Replace itwith a pure component condition that includes the package architecture.The Template summary property has this information already, but it isnot available from within the installation, and I'm not about to startwriting custom actions.