self-contained is stuck at 1.0.4.0

[JanDeDobbeleer]

Brief description of your issue

When installing from https://aka.ms/wingetcreate/latest/self-contained, it seems out of date with the latest release:

This is an older version of Winget-Create and may be missing some critical features.
For the latest version (v1.1.2.0), go to https://github.com/microsoft/winget-create/releases

Steps to reproduce

Install the latest self-contained:

Invoke-WebRequest 'https://aka.ms/wingetcreate/latest/self-contained' -OutFile wingetcreate.exe

Validate the version

.\wingetcreate.exe version

It's on 1.0.4.0

Telemetry Settings
------------------
The Windows Package Manager Manifest Creator collects usage data in order to improve your experience.
The data is anonymous and collected only by Microsoft.
By default, telemetry is enabled but can be disabled by running `wingetcreate settings` and editing your settings file.

WingetCreateCLI 1.0.4.0
Copyright (C) 2022 WingetCreateCLI

  new         Launches a series of questions to help generate a new manifest

  update      Updates fields of an existing manifest

  submit      Submits a valid manifest directly to the Windows Package Manager
              repo

  settings    Open settings

  token       Modifies the GitHub auth token cache

  cache       Manage downloaded installers stored in cache

  help        Display more information on a specific command.

  version     Display version information.

Expected behavior

I expect this to be on v1.1.2.0

Actual behavior

It's on 1.0.4.0

Environment

Not relevant

[ryfu-msft]

Hey @JanDeDobbeleer,

I apologize for the late reply. Regarding the self-contained exe, we are no longer supporting this as of #265 since WS2022 now supports the usage of app-execution aliases. We have left the vanity URL to point to the latest self-contained exe that we have available as to not break any pipelines that rely on it. Our docs have been updated with examples on how to use the msixbundle in your pipeline here.

If there is enough pushback from the community, I can bring this discussion up with the team, but as of right now this is our current decision.

[JanDeDobbeleer]

@ryfu-msft thanks for the answer and context. The thing is, doing this on every run is annoying:

# Download and install C++ Runtime framework package.
      iwr https://aka.ms/Microsoft.VCLibs.x64.14.00.Desktop.appx -OutFile $(vcLibsBundleFile)
      Add-AppxPackage $(vcLibsBundleFile)

I might need to have a look at if this can be cached, but an executable should never have external dependencies in my opinion.

[Masamune3210]

You don't have to do it on every run, just when first installing if the redist isn't already installed and once again if the requirement is ever upgraded.

As for the comment about nothing should have external dependencies, statically linking everything causes more memory usage and more storage usage. The whole point is to reuse code and not have a billion different copies floating around on the drive and in memory when it's not needed

[JanDeDobbeleer]

@Masamune3210 I install this on the fly in my GitHub action, I'm pretty sure I need to do that on every run as it's not an explicit installation path I can cache and reuse.

I'll close this as I seem to be the only one who has this request.