Create MSI installer as an exe wrapper

RESOLVED FIXED in Firefox 65

Status

()

enhancement
P2
normal
RESOLVED FIXED
Last year
6 months ago

People

(Reporter: RT, Assigned: mhowell)

Tracking

(Depends on 4 bugs, {feature})

unspecified
Firefox 65
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(relnote-firefox 65+, firefox65 fixed)

Details

User Story

As a system administrator in Active Directory environment, I want the convenience of an MSI installer provided by Mozilla, so I can deploy it easily in my organization.
As a system administrator, I can set properties through a MST file so that the installation is customized.

Acceptance criteria:
- MSI installer created as a wrapper of the exe installer
- MSI properties include available command line parameters (silent install, silent uninstall, configuration.ini file) as well as a way to  enable the installation of the native messaging app require for legacy website support extension. MSI properties can be set externally through an MST file
- 2 MSI installers are available, one for 32 bit installs and one for 64 bit installs and each locale has a dedicated MSI installer
- 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.

Target is shipping for Firefox 64.

Attachments

(5 attachments)

No description provided.
User Story: (updated)
Blocks: 1475512
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?
Flags: needinfo?(mhowell)
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).
Flags: needinfo?(mhowell)
Assignee: nobody → mhowell
Priority: -- → P2
(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
User Story: (updated)
: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?
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.
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
User Story: (updated)
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">
Flags: needinfo?(mhowell)
(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.
Flags: needinfo?(mhowell)
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.
Flags: needinfo?(mhowell)
(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.
Flags: needinfo?(mhowell)
Depends on: 1504244
Depends on: 1504248
Depends on: 1505377
Depends on: 1505436
Depends on: 1505462
Pushed by jwood@mozilla.com:
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
Depends on: 1505769
Depends on: 1506150
Pushed by thunderbird@calypsoblue.org:
https://hg.mozilla.org/comm-central/rev/3f3b0b711dbb
MSI Installer support workaround for TB. rs=bustage-fix
Depends on: 1506174
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.
Keywords: feature
You need to log in before you can comment on or make changes to this bug.