Config files to support silent installation

[denelon]

Some installers require a configuration file to specify parameters necessary for silent installation.

The manifest could be extended to support the data needed in a config file and could be created at install time on the local machine, or a file could be provided in addition to the manifest with some kind of pointer.

[jantari]

config files are useful and sometimes needed for:

• Inno Setup ( .iss )
• Install Shield ( .iss )
• MSI ( .mst )
• OracleDB Client ( .rsp )

Since the manifests are YAML, inline files through a syntax like:

extra_file:
  name: setup.iss
  content: |
    [SetupScript blabla]
    SILENT=TRUE
    LANG=1031
    ...

should be easy. The question is whether it's practical for long files and whether it's the right approach - maybe external files make more sense.

Because these file sometimes contain settings for highly subjective things like e.g. localization, it would be super duper amazing if we could JINJA2 them with defaults. Think about this:

extra_file:
  name: setup.iss
  content: |
    [SetupScript blabla]
    SILENT=TRUE
    LANG={{ LANG | 1031 }}

and then I install that package with a command like:

winget install PACKAGE --extra-vars "LANG=1033"

and I've customized the install language through a jinja2 replace in the setup.iss. The {{ LANG | 1031 }} expression means that if LANG is not defined, it defaults to 1031 (which i believe is german or english, can't remember)

This idea is probably silly and far from a spec - but the possibility to do something like this would be super! This would also allow one to choose a custom install directory which I believe was another open issue

[ethanbergstrom]

Quite a few installers require input parameters via silent installation - MSIs even support this natively. Manifests should definitely be able to handle taking in parameters (optional or required) for silent installation and pass them to the executable or MSI/MSIX.

[denelon]

I'd like a list of the top packages that actually require a config file for silent installation, not just parameters that need to be passed. It looks like IntelliJ falls into this category.

It would also help to know of a few specific packages that optionally take a config file. It looks like Microsoft SQL Server falls into this category.

I'm sure individuals would want to customize their configuration file in most cases. I'm thinking through how we could support a "default" configuration file in the community repository, and then a trivial mechanism to supply a different config file specific to the desired end state.

This could have implications on how "export/import" would behave as well as other scripted install scenarios.

[mimi89999]

IntelliJ does not require a config file anymore. Are there other packages that require it?

[SpecterShell]

Installers built by Setup Factory may need a config file for silent install: https://www.indigorose.com/webhelp/suf9/Program_Reference/Command_Line_Options.htm (/T is the path of temp files, not the path of program files) Softwares from Stardock (Fences, Start11, Start10, etc.) are using this kind of installer.

[denelon]

Thanks for concrete examples @SpecterShell.

[jantari]

@denelon

The licensed/paid version of FortiClient is an MSI installer that requires an MST transforms file in order to be installed (silently or non-silently) in order to connect to the correct management tenant and obtain its license from there. There is also a freely available version of FortiClient VPN to download, but it has fewer features and most corporate Fortinet customers will need to deploy the licensed version. The custom installer and MST file for this version of FortiClient is downloaded from the management platform, so basically every Fortinet customer gets a custom-built download. Because of this, this is a kind of software companies would distribute from their own internal winget repositories and not from the public winget-pkgs but it doesn't matter. There is more software like this - licensed and downloaded from some portal behind a login, and this software often uses MST for license or tenant registration information.

Microsoft Office 20xx Perpetual and Microsoft M365 Apps are installed by the Office Deployment Tool and the /configure <XML-CONFIG-FILE.xml> parameter. The XML config file is a required argument and it must be a path pointing to a readable file (readable to the Office Deployment Tool and the user account that runs it).

AutoDesk DWG TrueView requires an .ini file and parameters such as: Setup.exe /W /q /I DWGTrueView_2021_English_64bit_dlm\setup.ini /language en-us to install silently.

Janitza GridVis which is an IoT/industrial control system software that can either install in a standalone/single-client mode or a central-server mode with WebGUI and all, and it is an "install4j" setup that requires a response.varfile answer-file and parameters like: setup.exe -varfile "response.varfile" -q to install silently.

The Oracle Instant Client requires a .rsp response-file and parameters like setup.exe -silent -nowait -responseFile answerfile.rsp for silent installation.

In order to install a licensed version of PDF XChange Editor Plus you want to pass it a .xcvault license file via the install parameter KEYFILE=<PATH>. Technically there is also the option to use the KEYDATA= parameter and pass the license encoded as Base64 but that is very unreadable, you risk hitting Windows' 1024 character command-line length limit and it's also not preferable for other license management reasons. See: https://help.pdf-xchange.com/sysadmin/ and https://help.pdf-xchange.com/pdfxe10/index.html?switches-for-msi-installers_edpub.html.

There is another piece of software, not publicly available and rather specific to the industry my employer is in, that has an installer made with the "Qt Installer Framework". This software/framework requires a rather complex .qs file written in JavaScript and using callbacks to navigate a silent installation: https://doc.qt.io/qtinstallerframework/noninteractive.html

UltraVNC, while already available on winget-pkgs also requires a /loadinf="config.inf" parameter to install it with a desirable configuration. The defaults, chosen when no config-file is provided like right now, are only good for some limited usecases.

Microsoft wants us to deploy the new Microsoft Teams using a teamsbootstrapper.exe exe and a .msix file. One is the installer, one is the application package. This isn't really a "config file" but it is an additional file that has to be bundled in order for the install to "work" (well, in reality it doesn't work at all anyway but that's not your/wingets problem, that's just Microsoft being Microsoft: https://github.com/MicrosoftDocs/OfficeDocs-SkypeForBusiness/issues/10542) - in theory, if this bootstrapper did work, then it would also require the bundled .msix file.

Additionally, any number of in-house developed apps may require or optionally accept MST or similar response/answer/transform/config files during installation. Even many apps that are already in the winget-pkgs repo today, such as Mozilla Firefox, can optionally take MST transforms and an individual or corporate user of winget may want to distribute a "customized" version of any such ordinary software like Firefox through their winget package repository. This may be achieved a number of ways, in the case of Firefox specifically there's GPOs and Intune policies too, but MST files are another option and for some software maybe the only option. Also, some software may be deployed before a computer is joined to an MDM such as Intune or an Active Directory domain (such that GPOs would take effect) so pre-customizing it right during the install is the safest option. For example, we currently deploy the benign software "neovim", which is already available in winget-pkgs, with a custom MST transforms file that tells it to NOT put a shortcut on the desktop. There is no parameter or other way to prevent the Neovim MSI installer from creating a desktop shortcut, but an MST works.

---

All of that being said, could we not solve this already with ZIP files and nested installers? The ZIP file would just contain the MST/config/answer file we need for the setup to run and the parameter would be passed to the nested installer? I have not tried this, but it seems like it should work - but then again this issue is still open?

I hope I was able to help and some of these examples are useful.

[jantari]

I just tried deploying a licensed FortiClient (MSI + MST) using the following manifest (excerpt):

InstallerType: zip
NestedInstallerType: wix
Scope: machine
NestedInstallerFiles:
- RelativeFilePath: FortiClient.msi
InstallerSwitches:
  Custom: TRANSFORMS=FortiClient.mst REBOOT=ReallySuppress DONT_PROMPT_REBOOT=1 DESKTOPSHORTCUT=0
ProductCode: '{GUID}'
Installers:
- InstallerUrl: https://domain.tld/installers/FortiClient.zip
  Architecture: x64
  InstallerSha256: FILEHASH

and it worked flawlessly. @denelon Would you say ZIPs + NestedInstallers are a good way to achieve multi-file installs like what is asked here? Or would you consider it unsupported and we shouldn't rely on it working?

[denelon]

I wouldn't rely on it working since portable packages get different treatment in terms of how the path is hooked up. With administrator or Dev Mode enabled, we have a path available, but with user install and Dev Mode disabled, we end up with path cramming.

[jantari]

But InstallerType portable is not the same as InstallerType zip:

https://github.com/microsoft/winget-cli/blob/2fece93b79e3c844af3bb096bf0f5ed31389379e/schemas/JSON/manifests/v1.7.0/manifest.installer.1.7.0.json#L55-L69

Unless I'm misunderstanding, the behavior and handling of portable packages should not apply to ZIP + NestedInstaller packages.

[jantari]

Any new developments or comments on this?