Bootstrap api could be more useful

[DHancock]

I'm looking into providing an unpackaged framework dependent app installer to save space. This is more of a feature request than a bug.

Currently the c# Bootstrap.TryInitialise() api attempts to find and initialise a suitable WinAppSdk <major>.<minor>.<patch> version. The caller supplies the encoded <major>.<minor> part and the api determines the best patch version, if there is one.

However if only WinAppSdk 1.3.0 has been installed, a call to the TryInitialise() supplying version "1.2" fails even though a suitable sdk exists. It would make life easier if it succeeded and initialised the 1.3.0 version i.e. providing a "roll forward" function. That's assuming increments of the version won't include breaking changes (and really shouldn't according to semantic versioning). The roll forward scheme could be optional.

In a similar vein, Microsoft provides the latest WinAppSdk installer down load links with the <major>.<minor> version encoded into the url e.g.

 https://aka.ms/windowsappsdk/1.3/latest/windowsappruntimeinstall-x64.exe

It would be very useful to provide an alternative url with just the <major> version encoded into it.

If both are implemented then an unpackaged framework dependent app and it's installer won't have to be updated each time a new WinAppSdk 1.<minor> version is released. The bootstrap code would work as is, and if the installer needs to install a WinAppSdk, the download url for the latest version is always known (the installer could call the bootstrap code to see if a suitable sdk is available).

Further justification for this sort of scheme is that you cannot use the WinAppSdk installer to successfully instal version 1.2.5 after previously installing version 1.3.0 on a clean machine (the 1.2.5 DDLM packages aren't installed). That will cause the Bootstrap.TryInitialise() call to fail when supplying "1.2", i.e. old framework dependent installers will be broken.

I can write code in the app and the installer that works round these problems, but it seems quite brittle (I'm not a WinAppSdk or package manager expert, and I'd prefer not to have to probe Microsoft's download urls). It would be better if an official solution existed.

Background: If I include x86, x64 and arm64 self-contained apps in my installer, the installer size is 76MB. When the x64 version is installed, it takes 81MB. Even with fast internet and large capacity SSDs these days, that's a little too big for comfort even for a noddy hobby project.

[DrusTheAxe]

initialise a suitable WinAppSdk .. version...It would be very useful to provide an alternative url with just the version encoded into it.

Thank you for your feedback but WinAppSDK pivoting on major.minor is a ByDesign decision. This is explained in detail in 2.2. Decision 2: Breaking Change Boundary for Version 1.x. WinAppSDK uses Option B (major.minor).

You're advocating for Option A (major). This has been discussed and is informally referred to as "2.x" (because changing this rule would require a major version change, ironically enough) but the calculus hasn't reached the tipping point yet where Option A's tradeoffs outweigh Option B. I expect we'll get there eventually, we're just not there today.

If/when this occurs then yes, the Bootstrapper and other machinery would change to use major version (rather than major.minor) as the breaking change boundary.

you cannot use the WinAppSdk installer to successfully install version 1.2.5 after previously installing version 1.3.0 on a clean machine (the 1.2.5 DDLM packages aren't installed)

That's a bug and absolutely not the intention. Please create an Issue reporting the problem with repro steps and other information.

You should be able to install 1.2 and 1.3 (and 1.0, 1.1 and now 1.4) on the same machine and in any order. As they're all distinct package families they have no relation to each other as far as MSIX is concerned.*

* Other than the Singleton of course. But that's also ByDesign. You can install every version of WinAppSDK and you'll get all their appropriate packages and one Singleton package (the highest version).

That will cause the Bootstrap.TryInitialise() call to fail when supplying "1.2",

As I'd expect if 1.2 isn't registered for the user. The surprising part is the 1.2 installer didn't lay down packages if 1.3 was installed. If so something's amiss in the installer and needs investigation. Please report to help focus our efforts. Thank you!

[DHancock]

Thanks, I had naively assumed sematic versioning was being used. The rest of it makes sense now.

I've raised #3602