Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Switch to WiX v4 in Windows #894

Closed
yukawa opened this issue Mar 10, 2024 · 0 comments
Closed

Switch to WiX v4 in Windows #894

yukawa opened this issue Mar 10, 2024 · 0 comments

Comments

@yukawa
Copy link
Collaborator

yukawa commented Mar 10, 2024 •
edited
Loading

Description

WiX v3 will be EOLed on Feb 6 2025. It's time to switch to WiX v4 or newer.

https://www.firegiant.com/blog/2024/2/6/wix-security-releases-available/

WiX v3 is not the future

Now that WiX v4 has been out for almost a year and WiX v5 is nearing release, it's time to put WiX v3 out to pasture. WiX v3 is approaching its fifteenth birthday. (WiX v3.0.5419.0 was released 19-June-2009!) In software terms, that's ancient -- even as we've done eight releases to keep it running smoothly (he says modestly).

So we're giving WiX v3 a deadline (literally). Today's release of WiX v3.14.xxxxx starts the one-year clock: After 6-Feb-2025, there will be no future security fixes released in the WiX v3 line.

Version or commit-id

e87c83f

Environment

  • OS: Windows

Additional Information
@yukawa yukawa changed the title Switch to WiX v4 in Window Switch to WiX v4 in Windows Mar 10, 2024
hiroyuki-komatsu pushed a commit that referenced this issue Mar 13, 2024
@yukawa @hiroyuki-komatsu
Normalize quite in WiX rules
dc6df87 
This is a preparation to switch to WiX v4 (#894).

While there is an automated converter from WiX v3 rules to WiX v4 rules,
it normalizes all the single quotes in XML attributes to double quotes.

To minimize the diffs in the above process, this commit applies the same
normalization in prior.

This is a mechanical replacement. There must be no difference in the
final installer files.

#codehealth

PiperOrigin-RevId: 614782079
hiroyuki-komatsu pushed a commit that referenced this issue Mar 13, 2024
@yukawa @hiroyuki-komatsu
Normalize tag ending in WiX rules
d4cd83a 
This is a preparation to switch to WiX v4 (#894).

While there is an automated converter from WiX v3 rules to WiX v4 rules,
it normalizes all the tag ending as follows.

 * <SomeTag SomeAttr="" />
 * <SomeTag SomeAttr="">...</SomeTag>

To minimize the diffs in the above process, this commit applies the same
normalization in prior.

This is a mechanical replacement. There must be no difference in the
final installer files.

#codehealth

PiperOrigin-RevId: 614811737
hiroyuki-komatsu pushed a commit that referenced this issue Mar 13, 2024
@yukawa @hiroyuki-komatsu
Normalize new line in WiX rules
1745c8a 
This is a preparation to switch to WiX v4 (#894).

While there is an automated converter from WiX v3 rules to WiX v4 rules,
it normalizes every XML tag to a single line.

To minimize the diffs in the above process, this commit applies the same
normalization in prior.

This is a mechanical replacement. There must be no difference in the
final installer files.

#codehealth

PiperOrigin-RevId: 614834603
hiroyuki-komatsu pushed a commit that referenced this issue Mar 13, 2024
@yukawa @hiroyuki-komatsu
Normalize <CustomAction> attributes in WiX rules
e94b048 
This is a preparation to switch to WiX v4 (#894).

While there is an automated converter from WiX v3 rules to WiX v4 rules,
it mechanically replaces

  <CustomAction ... BinaryKey="mozc_installer_helper.dll" ... />

with

  <CustomAction ... BinaryRef="mozc_installer_helper.dll" />.

To minimize the diffs in the above process, this commit applies the same
normalization in prior.

This is a mechanical replacement. There must be no difference in the
final installer files.

#codehealth

PiperOrigin-RevId: 614945481
hiroyuki-komatsu pushed a commit that referenced this issue Mar 13, 2024
@yukawa @hiroyuki-komatsu
Move <Directory>...</Directory> to the last in WiX rules
b4d988c 
This is a preparation to switch to WiX v4 (#894).

While there is an automated converter from WiX v3 rules to WiX v4 rules,
it <Directory> section to the last part in the WiX rule file.

To minimize the diffs in the above process, this commit applies the same
normalization in prior.

This is a mechanical replacement. There must be no difference in the
final installer files.

#codehealth

PiperOrigin-RevId: 614965536
hiroyuki-komatsu pushed a commit that referenced this issue Apr 11, 2024
@yukawa @hiroyuki-komatsu
Simplify installer{,_oss}_64bit.wxs
6df9da5 
This is a preparation to switch to WiX v4 (#894).

Historically Mozc's WiX rules have had the following actions in
 <InstallExecuteSequence>

 * <SelfRegModules />
 * <SelfUnfegModules />,

which are used for so-called SelfRegistration [1].

However we have explicitly stopped supporting SelfRegistration [2]
because 1) we believe SelfRegistration is not the best approach for
end user and production and 2) Windows Installer, which Mozc has already
relied on, is a supserset of SelfRegistration anyway.

With above let's simplify our WiX rules to make it clear that Mozc no
longer relies on SelfRegistration in any possible way. Simplifying WiX
rules also helps our migration from WiX v3 rules to WiX v4 rules.

There must be no user observable behavior change in Mozc64.msi.
I have actually confirmed it by manually checking InstallExecuteSequence
table in Mozc64.msi by using Orca [3].

#codehealth

 [1]: https://learn.microsoft.com/en-us/windows/win32/com/self-registration
 [2]: 4e12191
 [3]: https://learn.microsoft.com/en-us/windows/win32/msi/orca-exe

PiperOrigin-RevId: 623631510
@yukawa yukawa changed the title Switch to WiX v4 in Windows Switch to WiX v5 in Windows Apr 12, 2024
@yukawa yukawa changed the title Switch to WiX v5 in Windows Switch to WiX v4 in Windows Apr 12, 2024
hiroyuki-komatsu added a commit that referenced this issue Apr 25, 2024
@hiroyuki-komatsu
Update BUILD_OSS to 5448
7a656f2 
Features
* Updated the word dictionary
* Improved the usability of era-to-ad conversion (れいわ６ねん→2024年)

Bug fix
* Linux: Prevent executing multiple candidate windows (#912)

Build
* Updated the Protobuf version: v26.0 → v26.1 (#913)
* Updated the Qt version: 6.6.3 → 6.7.0 (#911)
* Linux: Deprecated the GYP build
* Windows: Update the WiX version: v3.14 → v4.0.5 (#894)

PiperOrigin-RevId: 627570103
hiroyuki-komatsu pushed a commit that referenced this issue Sep 29, 2024
@yukawa @hiroyuki-komatsu
Add dotnet_tool_repository rule to download wix
4e7b736 
This is a preparation to use Bazel to build Mozc for Windows (#948).

With this commit, we can start referencing to wix.exe from Bazel rules.

Note that dotnet-tools.json, which we introduced for #894 [1], does not
work well with Bazel because we cannot assume current working directory
when running Bazel action.  We instead download the WiX executable with

  --tool-path

option so that WiX can be executed from any current working directory.

Note also that there must be no observable behavior change in GYP build.

 [1]: cbd5556

PiperOrigin-RevId: 680138030
@yukawa yukawa mentioned this issue Oct 9, 2024
Closed
yukawa added a commit to yukawa/mozc that referenced this issue Oct 9, 2024
@yukawa
Set Bitness="always32" for Omaha related reg keys
3d2e18a 
Omaha [1] is still a 32-bit app. Thus registry values need to be placed
under WOW6432Node.

This is probably a regression in my previous commit [1], which updated
WiX version from WiX v3 to WiX v4 (google#894).

Closes google#1072.

 [1]: https://github.com/google/omaha
 [2]: google@cbd5556
@yukawa yukawa mentioned this issue Oct 9, 2024
Merged
yukawa added a commit to yukawa/mozc that referenced this issue Oct 9, 2024
@yukawa
Set Bitness="always32" for Omaha related reg keys
8e14abd 
Omaha [1] is still a 32-bit app. Thus registry values need to be placed
under WOW6432Node.

This is probably a regression in my previous commit [1], which updated
WiX version from WiX v3 to WiX v4 (google#894).

Closes google#1072.

 [1]: https://github.com/google/omaha
 [2]: google@cbd5556
yukawa added a commit to yukawa/mozc that referenced this issue Oct 9, 2024
@yukawa
Set Bitness="always32" for Omaha related reg keys
73c4422 
Omaha [1] is still a 32-bit app. Thus registry values need to be placed
under WOW6432Node.

This is probably a regression in my previous commit [1], which updated
WiX version from WiX v3 to WiX v4 (google#894).

Closes google#1072.

 [1]: https://github.com/google/omaha
 [2]: google@cbd5556
hiroyuki-komatsu pushed a commit that referenced this issue Oct 10, 2024
@yukawa
Set Bitness="always32" for Omaha related reg keys (#1073)
9f62caf 
Omaha [1] is still a 32-bit app. Thus registry values need to be placed
under WOW6432Node.

This is probably a regression in my previous commit [1], which updated
WiX version from WiX v3 to WiX v4 (#894).

Closes #1072.

 [1]: https://github.com/google/omaha
 [2]: cbd5556

PiperOrigin-RevId: 684282939
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@yukawa