1475510 - Create MSI installer as an exe wrapper

Status: RESOLVED FIXED

(Firefox :: Installer, enhancement, P2)

Comment 1

[Romain Testard [:RT]]

Matt, https://bugzilla.mozilla.org/show_bug.cgi?id=231062#c420 says "Use WIX variables for details such as the language, version, platform, package/upgrade codes, and installer file, to ease turning the file into a template." - would that make sense for us to do here?

Comment 2

[Molly Howell (she/her) (no longer active)]

Yes, that's exactly what I'm planning on doing. It makes it easier for the build system to be able to fill in that kind of information (which has to be done during build time).

Comment 3

[Romain Testard [:RT]]

(In reply to Matt Howell [:mhowell] (PTO July 16 - July 27) from comment #2)
> Yes, that's exactly what I'm planning on doing. It makes it easier for the
> build system to be able to fill in that kind of information (which has to be
> done during build time).

Thanks, updating the user story so it's included

Comment 4

[Justin Wood (:Callek)]

:Mhowell,

I'm also looking for extra confirmation on some stuff:

.msi will wrap a *already signed* .exe installer? (And we can't have an unsigned .exe installer in it?)
.msi will itself need to be signed?
We will use an explicit different .msi per locale?
Will there be an .msi for the stub installer?

Comment 5

[Molly Howell (she/her) (no longer active)]

I believe the .msi will have to wrap an already signed .exe, yes. The signature on the .msi (which we do also need) covers the content of the bundled .exe, but since that won't be available at the time the .exe is run I think signing it too is still required.

We'll need an explicit .msi per full installer, so that means we need one per locale *if* we don't want to block on having multilocale installers available, which I would say we probably don't.

I don't expect any need to cover the stub installer, only the full.

Comment 6

[Molly Howell (she/her) (no longer active)]

Attachment: Prototype WiX file for MSI wrapper

This WiX XML file will generate an MSI wrapper over the specified full installer. The variable defines at the top are what need to be set during the build; the rest of the file is static. You'll of course have to change the path to the installer to be able to use this file, but after doing that and downloading the WiX tools (https://github.com/wixtoolset/wix3/releases/) you can generate a .msi file from this by running the following WiX commands:

candle msi_wrapper.wxs
light -cultures:neutral -sw1076 -sw1079 msi_wrapper.wixobj

Comment 7

[Kim Moir [:kmoir] ET]

mhowell: where do you plan to store the wix file in tree?  Also, I assume the source of truth for the guid will continue to be https://searchfox.org/mozilla-central/source/browser/confvars.sh#57 and the wix file will be updated to reflect this?

Where are the existing sources of truth for the UpgradeCode and the <Component Id="EmptyComponent" Guid="55a76b76-7496-4b47-a7a6-c5fbdd5e51a4">

Comment 8

[Molly Howell (she/her) (no longer active)]

(In reply to Kim Moir [:kmoir] ET from comment #7)
> mhowell: where do you plan to store the wix file in tree?

Hmm, I hadn't really thought about that. I guess /browser/installer/windows/msi/ (which does not currently exist) seems like the obvious spot for it.

> Also, I assume the source of truth for the guid will continue to be
> https://searchfox.org/mozilla-central/source/browser/confvars.sh#57 and the
> wix file will be updated to reflect this?

Well, since we're using MSI in kind of a strange and confusing way here, none of these GUID's are used for anything meaningful. In a normal MSI, the product ID would be used to determine whether the product is already installed or not, but this MSI won't actually install anything (as far as the Windows Installer framework is concerned). So in our usage this GUID is meaningless and only there because the schema requires one.

For that reason I'd kind of prefer to specifically avoid using any identifier that actually refers to something already, so that we can reserve it for if we ever end up building a "real" MSI installer that's not just a wrapper. So because of that, I generated a new GUID to fill in there, and I think it's better to keep that one in place.

> Where are the existing sources of truth for the UpgradeCode and the
> <Component Id="EmptyComponent" Guid="55a76b76-7496-4b47-a7a6-c5fbdd5e51a4">

Same thing for these two, except we don't even have an existing source of truth for them because components and upgrade codes are MSI-specific concepts.

Comment 9

[Kim Moir [:kmoir] ET]

It would probably be good use the wix file as a template and copy it during the repackage step to update values that change like version, locale, architecture which I can do in my patches.

Have you tried this wix file?  Does it successfully create a working msi?  I'm still waiting for my windows loaner to test out my patches.

Comment 10

[Molly Howell (she/her) (no longer active)]

(In reply to Kim Moir [:kmoir] ET from comment #9)
> Have you tried this wix file?  Does it successfully create a working msi? 
> I'm still waiting for my windows loaner to test out my patches.

Yes, and yes. To build it you need either an installation of WIX or the copy of MozillaBuild from bug 1476980 comment 2 that already has it, and the two commands from comment 6 are the only ones that need to be run; the first outputs a .wixobj and the seconds turns that into a .msi.

Comment 11

[Justin Wood (:Callek)]

Attachment: Bug 1475510 - Use locale from dep job attributes. r=aki

Comment 12

[Justin Wood (:Callek)]

Attachment: Bug 1475510 - Add mozharness support for repackage-msi. r=aki

Comment 13

[Justin Wood (:Callek)]

Attachment: Bug 1475510 - Taskgraph msi generation. r=aki

Comment 14

[Justin Wood (:Callek)]

Attachment: Bug 1475510 - Add repackage-msi signing. r=aki

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d6318768c81d
Use locale from dep job attributes. r=aki
https://hg.mozilla.org/integration/autoland/rev/ab016cfaccb9
Add mozharness support for repackage-msi. r=aki
https://hg.mozilla.org/integration/autoland/rev/3c5cd30ce06b
Taskgraph msi generation. r=aki
https://hg.mozilla.org/integration/autoland/rev/af7e0bd71e96
Add repackage-msi signing. r=aki

Comment 16

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/d6318768c81d
https://hg.mozilla.org/mozilla-central/rev/ab016cfaccb9
https://hg.mozilla.org/mozilla-central/rev/3c5cd30ce06b
https://hg.mozilla.org/mozilla-central/rev/af7e0bd71e96

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/3f3b0b711dbb
MSI Installer support workaround for TB. rs=bustage-fix

Comment 18

[Pascal Chevrel:pascalc (PTO until April 26)]

I am adding a release note for Firefox Nightly only about this feature (also added the feature keyword to the bug btw):

Release Note Request (optional, but appreciated)
[Why is this notable]: additional installation mechanism for Windows users
[Affects Firefox for Android]: No
[Suggested wording]: Firefox on Windows can now be installed with an MSI installer
[Links (documentation, blog post, etc)]: http://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central-l10n/

I am leaving the 'relnote?' flag set as we will want a release note when it ships on beta/release and the note will probably be worded differently and link to a blog post or documentation about the feature.

Comment 19

[Tom Prince [:tomprince]]

https://hg.mozilla.org/releases/mozilla-esr60/rev/ffdd345eb0ce

Comment 20

[Jorg K (CEST = GMT+2)]

https://hg.mozilla.org/releases/comm-esr60/rev/3c708fe6e9951c2fc5857767a71e2ff0c49d854d