MSI Installer

[Romanitho]

Hi guys,

I'm thinking for few days/weeks now to package WAU into a MSI package. This would involve breaking changes I guess. My ideas so far:

• Install WAU to ProgramFiles
• WAU data (like logs mainly) to ProgramData
• MSI would take care of registry (with config in it)
• MSI would manage update smoother and better (no Invoke-PostUpdateActions.ps1 anymore)
• No WAU shortcut or bat anymore to install it
• Select only few parameters from the GUI installer (as all settings are customisable via GPO or via install switch in cli) - mainly for home users
• and much more...

For that, I think about WIX and Github Actions to continue to have all things full automated to be as transparent as possible in the build.

@KnifMelti @AndrewDemski-ad-gmail-com

[Romanitho]

This will involve also new versioning system probably.
Today we have something like 1.19.1 for stable version
and 1.19.2-9 for nightly builds (that will pop to 1.19.2 when becoming stable)

We could change this for something like:
1.19.2.9 for Nightly builds
and by convention x.x.x.100 for stable, so 1.19.2.100 would be the new stable release in this example. Next stable one would be 1.19.3.100 for minor changes or 1.20.0.100 for major changes.

Don't really like the ".100" but I didn't find something better yet 😅

[Romanitho]

Yes, I was thinking about WIX. I'm trying to learn a bit about how it works 😅

Regarding the versionning, maybe we need to think about something else then.

[AndrewDemski-ad-gmail-com]

Why no change it to something similar to what Citrix has done some time ago?
major.minor[.build[.revision]] where each part of identifier was capped at 255.
Modern standard expanded those sections a bit to 16bits, but IMHO that would be an overkill.

Idea for versioning:

octet	definition	max value	sample value
major	Year od current release	255	23
minor	month of current release	255	3
build	day of current release	255	12
revision	any hotfix if necessary	255	0

That would produce WAU release with VersionInfo identified as 23.3.12.0 (simple date formatting would be enough).

It is still consistent with winget schema for packages
https://github.com/microsoft/winget-pkgs/blob/01e23bc050d119377b166bc2e312890c6f11ff1c/schemas/JSON/validation/ValidationSchema.1.0.0.json#L13-L16

    "ValidationVersion": {
      "description": "Version of validation file. Used to handle breaking changes, should the need arise.",
      "type": "string",
      "pattern": "^[0-9]+\\.[0-9]+\\.[0-9]+$"

[Romanitho]

The "date" version could be something easy to implement for sure...
But we need to be sure that we do not run the same day a nightly build with a potential stable one.

[Romanitho]

this powershell cmd could generate our new semver:
Get-Date -Format %y.%M.%d.%H%m
24.3.13.1740

[AndrewDemski-ad-gmail-com]

@KnifMelti you may like this introduction to WIX
https://www.codeproject.com/Tips/105638/A-quick-introduction-Create-an-MSI-installer-with

[AndrewDemski-ad-gmail-com]

Hi guys,

I'm thinking for few days/weeks now to package WAU into a MSI package. This would involve breaking changes I guess. My ideas so far:

• Install WAU to ProgramFiles

achievable already using existing scripted logic by changing the target folder

• WAU data (like logs mainly) to ProgramData

That one is easy, either using that recent settings.JSON file approach from one of PRs or something similar

• MSI would take care of registry (with config in it)

Using Installer to provide automated resolve of WAU variables would give only the ARPINSTALLLOCATION, major settings should land:

• in defaults config file
• Policies Regkey
• in separate HKLM/Software/WAU location (with option for overrides in HKCU)

• MSI would manage update smoother and better (no Invoke-PostUpdateActions.ps1 anymore)

scripting languages natively interpreted during installation include

• vbscript
• jscript
  more details here:
  https://learn.microsoft.com/en-us/windows/win32/msi/summary-list-of-all-custom-action-types
  https://learn.microsoft.com/en-us/windows/win32/msi/scripts

guys from Advanced Installer had some idea but that would require creating an obfuscated DLL which would run the inline script in the background (risking an another false positive for sophisticated inline script).

• No WAU shortcut or bat anymore to install it

so.. winget initiated by WAU would update.. WAU?
What about that brain-dead executable launcher which could solve the problem with false positives returned by AVs?

• Select only few parameters from the GUI installer (as all settings are customisable via GPO or via install switch in cli) - mainly for home users
• and much more...

For that, I think about WIX and Github Actions to continue to have all things full automated to be as transparent as possible in the build.

That would mean adding WAU to winget repo on github.
Yet the idea of calling winget install --id WAU.WAU using package definition with InstallMode : Interactive would be nice.

[KnifMelti]

scripting languages natively interpreted during installation include

vbscript
jscript

It can also be in Powershell

[AndrewDemski-ad-gmail-com]

Assuming that WAU lands in winget repo, those could be treated as separate products.

…

________________________________ From: Romain ***@***.***> Sent: 12 March 2024 22:54 To: Romanitho/Winget-AutoUpdate ***@***.***> Cc: Andrzej Demski ***@***.***>; Mention ***@***.***> Subject: Re: [Romanitho/Winget-AutoUpdate] MSI Installer (Discussion #582) The "date" version could be something easy to implement for sure... But we need to be sure that we do not run the same day a nightly build with a potential stable one. — Reply to this email directly, view it on GitHub<#582 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ASAJCPUAU662N7SW55Y54CDYX52Q5AVCNFSM6AAAAABER4U5VWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DONRVGQYTM>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[Romanitho]

could be. i'm not skilled enough for MSI building, but we might (I guess) ensure that we cannot have both version (stable and preview) installed at the mean time on a device.

[AndrewDemski-ad-gmail-com]

Why not?
two distinct INSTALLDIRs and two sets of tasks in the scheduler.
Let the fun begin:)

[Romanitho]

First tests:
https://github.com/Romanitho/WAU-MSI/releases/tag/v1.20.0

New substructure:
https://github.com/Romanitho/WAU-MSI/tree/main/Sources/Wix

Updated GitHub actions:
https://github.com/Romanitho/WAU-MSI/actions/workflows/WAU-CreateNewVersion.yml

So far, WAU installs files to program files. Still have to work on registry entries and scheduled task, but at least, MSI are created successfully

[Romanitho]

I also removed the preversion that used to be created by the nightly builder. This way, even pre version nightly builds are like this 1.19.3 -> 1.19.4

Also, I disabled the automerge of dependabot that creates nightly for nothing. I'll merge manually when other PR are pushed.