The MSI has no dialogs, so it cannot say it finished or let anyone choose where it goes

[A13xB0]

Asked for while working #499: the installer should say it installed successfully, and let people choose the install location.

Neither is possible with the current toolchain, so this is the decision rather than the change.

Where it stands today

The installer is built on Linux by wixl, and wixl builds no dialogs — GNOME/msitools#3, "Add UI support", still open. The tree already says so in two places, packaging/windows-msi.sh:

What that costs is the installer's user interface: wixl builds no dialogs, so msiexec shows a progress bar and takes its answers from the command line instead.

and packaging/meshbench.wxs, which sets ARPNOMODIFY for the same reason: a Modify button would open an installer with nothing in it.

So a double-clicked .msi shows a progress bar and closes. Nothing says it worked, which is its own small version of the #499 complaint — the thing runs and then there is silence.

Choosing a location already works, but only as a switch. INSTALLDIR is a real property and windows-msi.sh appends it to SecureCustomProperties so it survives elevation, which verify-msi.sh checks. docs/install.md documents all three:

msiexec /i meshbench-0.2.0-windows-x86_64.msi INSTALLDIR="D:\Tools\MeshBench"
msiexec /i meshbench-0.2.0-windows-x86_64.msi MSIINSTALLPERUSER=1
msiexec /i meshbench-0.2.0-windows-x86_64.msi ADDLOCAL=Complete,DesktopShortcut

A person who double-clicks the file never sees any of that, and typing an msiexec line is not what "choose where to install" means to them.

What getting both would take

WixUI_InstallDir is exactly this pair — a Browse dialog for INSTALLDIR, and the standard "Completed the MeshBench Setup Wizard" finish dialog — and it comes from WixToolset.UI.wixext, which means the real WiX toolset rather than wixl.

WiX v5/v6 ships as a .NET tool and does run on Linux, so the "no Windows runner" constraint in windows-msi.sh survives. What changes:

• a .NET SDK on lab-2204, the self-hosted runner the windows job is pinned to, plus dotnet tool install --global wix and the UI extension
• meshbench.wxs rewritten to the v4+ schema — different namespace, Product becomes Package, Feature/Component authoring shifts
• wixl-heat replaced by WiX's own harvesting, which is what produces the Bundle ComponentGroup from the staged directory
• verify-msi.sh revisited, since it reads tables with msiinfo and would now also want to assert the UI tables exist — the same shape as the Shortcut/INSTALLDIR checks it already makes
• the upgrade behaviour re-proved: UpgradeCode, the derived ProductCode, and RemoveExistingProducts After="InstallValidate" are the parts of that file with real reasoning behind them and the parts a rewrite is most likely to quietly change

That last one is why this is worth doing deliberately rather than as a tail of a bug fix. An installer that puts a second copy beside the first is a worse outcome than one with no dialogs.

Smaller things worth deciding first

• Say it finished, without a UI. There is no completion dialog in the basic UI level and no way to add one without dialogs. The nearest honest thing is for the application to notice a first run after an install and say so, which is a different feature and probably not what was wanted.
• ARPNOMODIFY can come off if there are ever dialogs, since a Modify button would then do something.
• Whether the per-user install (MSIINSTALLPERUSER=1) should be the offered choice in that dialog too, since it is the one that needs no administrator.

I have not attempted any of it: there is no Windows MSI toolchain on the machine I verified #499 on, so a rewrite of the packaging path is not something I could build or test, and an untested installer is the one artefact where that matters most.

[A13xB0]

What I would do about this

Three things, in the order I would do them.

1. Notice that most of the felt problem was #499, and is already fixed

This was asked for alongside "the MSI installs, the application starts, and then vanishes". The install was never the broken half — #499 turned out to be the Start menu shortcut passing no arguments, so you installed, clicked the entry, and nothing happened. That reads as "the installer did not work" no matter what the installer said.

With #503 the shortcut opens the workbench. So the sequence a person actually judges an install by — install, click, see the application — now works end to end. That is worth confirming before spending anything on dialogs, because it changes what is left from "the install is silent and broken" to "the install is silent", which is a much smaller complaint.

2. Set ARPINSTALLLOCATION, which is a real gap and needs no new toolchain

Apps and Features shows an empty Install location today. Measured on this machine, against the installed 0.0.5:

DisplayName     : MeshBench
DisplayVersion  : 0.0.5
InstallLocation :
Publisher       : MeshBench
EstimatedSize   : 424697
URLInfoAbout    : https://github.com/MeshBench/meshbench

meshbench.wxs sets ARPPRODUCTICON, ARPURLINFOABOUT and ARPNOMODIFY, and not this one. So Windows knows where it put the files and does not tell anybody, in the one place a person goes to ask.

That is half of "let people choose where to install" — being able to see where it went — and it costs no dialogs. It cannot be a plain <Property> because [INSTALLDIR] is not resolved until install time; it wants a type 51 custom action sequenced after CostFinalize.

And the mechanism is already in the tree. windows-msi.sh already post-processes the built package with exactly this shape:

msibuild "$out" -q "UPDATE \`Property\` SET \`Value\`='$secure;INSTALLDIR;MSIINSTALLPERUSER'
  WHERE \`Property\`='SecureCustomProperties'"

so a pair of INSERTs into CustomAction and InstallExecuteSequence is the same trick again, and verify-msi.sh already reads tables with msiinfo, so it can assert the row rather than trusting it. Whether wixl would author it directly I could not confirm — its CustomAction support is partial — but the post-processing route does not depend on that.

I have not written it, because I cannot build or check an .msi here: wixl, msiinfo and msibuild are Linux tools and this is the Windows machine. It wants doing where the package is built.

3. Treat the dialogs as after the first release, not before it

The folder chooser and the "Completed the MeshBench Setup Wizard" dialog are one thing: WixUI_InstallDir from WixToolset.UI.wixext, which means the real WiX toolset rather than wixl. WiX v5/v6 ships as a .NET tool and does run on Linux, so the "no Windows runner" constraint in windows-msi.sh survives — but the work is not the dialogs, it is everything that has to be re-proved around them:

• a .NET SDK on lab-2204, plus the tool and the UI extension
• meshbench.wxs rewritten to the v4+ schema — Product becomes Package, StandardDirectory replaces the Directory nesting, MajorUpgrade replaces the hand-authored Upgrade/UpgradeVersion pair
• wixl-heat replaced by WiX's own harvesting for the Bundle ComponentGroup
• verify-msi.sh revisited
• the upgrade behaviour re-proved. UpgradeCode, the version-derived ProductCode, and RemoveExistingProducts After="InstallValidate" are the parts of that file with real reasoning behind them, and the comments say why each is the way it is. An installer that leaves two copies side by side is a worse outcome than one with no dialogs, and that is precisely what a schema rewrite is most likely to change quietly.

That last point is the whole argument for not doing it now. It is polish on a package that works, and the risk is concentrated in the one behaviour nobody would notice being broken until a second release existed to upgrade from.

What has changed since I first wrote this issue is that the upgrade path is now testable: this Windows machine has 0.0.5 installed from the real MSI, so install → upgrade → confirm one copy → uninstall → confirm clean is a loop somebody can actually run rather than reason about. That is the missing half. If you want the migration, it is worth doing with that loop in place, and I can drive it.

One thing worth deciding while you are there

If a dialog does happen, the choice more people need is not the folder but per-user versus per-machine: MSIINSTALLPERUSER=1 installs under the profile and asks for no administrator at all, and ALLUSERS=2 is already set so the package supports both. Somebody without admin rights on their own laptop is stopped today unless they find that switch in docs/install.md. WixUI_InstallDir gives the folder; the scope wants its own thought.

Summary

• now, free: confirm cmd: a bare invocation opens the workbench (#499) #503 makes install-then-click work, which is most of what this was about
• now, small: ARPINSTALLLOCATION, via the msibuild post-processing already used for SecureCustomProperties
• after the first release: the WiX migration, with a real install/upgrade/uninstall loop on Windows behind it

Happy to do the second and to drive the third whenever you want it.

[A13xB0]

Yes — and the place it goes is the same dialog that would say it finished

Asked whether a WiX migration would let the installer show the logo. It would, and it is a better argument for the migration than I gave it credit for, because the branding and the "it installed successfully" ask are the same screen.

What WiX gives you

WixUI takes two bitmaps, set as variables beside the dialog set:

<WixVariable Id="WixUIBannerBmp" Value="packaging/branding/banner.bmp"/>
<WixVariable Id="WixUIDialogBmp" Value="packaging/branding/dialog.bmp"/>

variable	size	where it appears
WixUIDialogBmp	493 × 312	the full left panel of the Welcome and Completed dialogs
WixUIBannerBmp	493 × 58	the strip across the top of every dialog in between

So the card would be the first thing somebody sees when they double-click the .msi, and the last thing they see is that same panel beside "Completed the MeshBench Setup Wizard". That is the whole of what was asked for in this issue, in one screen, rather than a dialog that says it worked and looks like every other installer.

There are also WixUIExclamationIco, WixUIInfoIco, WixUINewIco and WixUIUpIco if the small glyphs matter, and ARPPRODUCTICON — already set — stays as it is.

Today none of this is reachable. With no dialogs the only branding an MSI can carry is the Apps and Features icon and the shortcut icon, both of which are already done. There is nowhere else to put a logo.

What the repository already has, and what it does not

docs/brand/meshbench-card.png      1200 × 630
packaging/icons/meshbench.svg      48 × 48 viewBox, the mark
packaging/icons/meshbench-512.png  512 × 512   (plus 256, 128, 64, 48, 32, 24, 16)

Neither bitmap can be the card dropped in unchanged:

• the card is 1.90:1, the dialog panel is 1.58:1 — a crop or a re-layout, not a resize
• the banner is 8.5:1, which is a wordmark-and-mark strip and not a crop of anything that exists

And WiX wants .bmp, not PNG — no alpha, and the images are fixed-size rather than DPI-scaled, so they are soft on a high-DPI display. That is a real cost and worth knowing before somebody spends an afternoon on artwork: it is a 2001-era dialog with a picture in it, not a modern installer.

The tidy way to produce them is the way the .ico and .icns are already produced — rendered from committed sources at exact sizes in packaging/, not resampled by hand. meshbench.svg is there, so rsvg-convert (or ImageMagick) into .bmp at 493 × 312 and 493 × 58 would be one step in windows-msi.sh beside the icotool call that already runs. That is a new packaging dependency and wants the one-line justification CLAUDE.md asks for.

Where this leaves the recommendation

Unchanged in order, but the third item is worth more than I said:

1. now, free — confirm cmd: a bare invocation opens the workbench (#499) #503 makes install-then-click work
2. now, small — ARPINSTALLLOCATION, via the msibuild post-processing already used for SecureCustomProperties
3. after the first release — the WiX migration, which now buys a folder chooser, a per-user/per-machine choice, a completion dialog and the brand card on the first and last screens, all from the same piece of work

If the artwork is wanted, the two .bmp sources are worth deciding on before the migration rather than during it — a 493 × 312 crop of the card, and a 493 × 58 strip that does not exist yet.

[A13xB0]

Fixed by #534, merged into windows-child-windows. Both asks are in, and the logo with them.

What it does now

Built by the WiX toolset instead of wixl. WiX 5 is a .NET tool and runs on Linux, so the "no Windows runner" property this job has always had still holds.

• Asks where to go — WixUI_InstallDir's Destination Folder page, with a Change… button
• Says when it has finished — "Completed the MeshBench Setup Wizard"
• Shows the brand — the mark and wordmark on the first and last pages, the mark in the banner on the ones between
• Reports its install location to Apps and Features, which was blank
• Keeps the folder you chose across an upgrade
• The licence page is skipped: MeshBench is GPL-3.0-or-later, which is not a licence anybody must accept before running the program, and asking somebody to tick that they had would state something untrue about it

Every msiexec switch still works, and /qn still installs silently.

Driven end to end on Windows

Against a package built from this source, under a separate UpgradeCode so nothing touched the installed 0.0.5:

	result
install with INSTALLDIR=C:\MBTrial	exit 0, ARP shows 0.0.6 at C:\MBTrial\
upgrade, no location given	exit 0, one entry, still at C:\MBTrial, nothing in Program Files
uninstall	exit 0, no entries, no files
MSIINSTALLPERUSER=1	lands under %LOCALAPPDATA%\Programs

The wizard itself was screenshotted page by page rather than reasoned about, which is how the first attempt at the artwork was caught: WixUIDialogBmp is the whole dialog background and WiX draws its text on top, so a full-bleed card put dark artwork behind dark text and neither could be read. The artwork sits in a band down the left now, with the rest left light for the text.

Two things worth knowing

ALLUSERS is patched after the build. This package has always been dual-purpose — per-machine by default, per-user with MSIINSTALLPERUSER=1, which is what somebody without administrator rights needs. WiX 4 removed the option and emits ALLUSERS=1, so msibuild puts the 2 back and verify-msi.sh checks it. Dropping a documented install route to suit a schema was the alternative.

The bitmaps are composed with Pillow, not ImageMagick. The obvious one-liner used magick, which is ImageMagick 7; lab-2204 is Ubuntu 22.04 and apt gives it version 6, whose command is convert. That would have worked where it was written and failed at the first release cut after merging.

What guards it

verify-msi.sh now asserts the four dialogs, the ARP action and the registry value an upgrade reads back — a build that quietly lost the dialogs would undo the reason for the move. The WiX install steps are idempotent, because a persistent self-hosted runner would otherwise fail the second release on "tool 'wix' is already installed".

New on the runner: dotnet and the wix tool, plus python3-pil; wixl drops off.

[A13xB0]

Reopening: the dialogs were reverted tonight, so this is true again.

They were built by the WiX toolset, and WiX cannot build an MSI on Linux at
all. Not a bug to work around - it needs Windows' own msi.dll to write the
database. Proven by running the toolset directly:

• every Directory/@Name is refused as "not a relative path", whatever the
  name - MeshBench, Mesh, mb, A, abc - on a machine with a working
  locale
• remove the Name and it compiles, then dies on
  DllNotFoundException: Unable to load shared library 'msi.dll'
• WiX 6.0.2 behaves identically; WiX 7 will not run without accepting
  the Open Source Maintenance Fee EULA

Its own first line of output says so: WIX0000: The WiX Toolset only supports Windows. All behavior after this point is undefined. The MSI built during
development on a Windows machine; it has never built in this pipeline, because
the Windows job failed before reaching it every time.

So 0.0.6 ships the wixl installer again (#578), which is what v0.0.5 shipped.
No released behaviour regresses - the dialogs were never in a release - and
docs/install.md now says the installer asks nothing and gives the msiexec INSTALLDIR= and MSIINSTALLPERUSER=1 switches instead of describing a prompt
that will not appear.

What closing this actually requires: building the installer on a Windows
runner. windows-latest is free for this repository, but icotool and
msitools are Linux-only, so the job splits into stage-on-Linux, wix-on-
Windows, fix-up-on-Linux with the bundle moving between them. That is a change
to the shape of the pipeline rather than to meshbench.wxs, and it is the only
route to the dialogs.