Unpackaged WinUI3 desktop app does not start up on Windows 11

[rcohn]

Hello -

Does anybody know of reasons why an unpackaged WinUI3 desktop app would not start up on Windows 11?

We're using Microsoft.WindowsAppRuntime.Redist.1.0.0 and WindowsAppSDK.Cs.Extension.Dev17.Standalone.vsix (vc_redist.x64) to support the app. The app has been opening and working fine on Windows 10.

Any guidance would be greatly appreciated.

Thank you.
Robert

[dimohy]

I also use Windows 11, but it works just fine, so I need to know something more.

If it is V1.1, it is recommended to add <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained> to the project settings and publish as `self-contained' when publishing.

This should work as it deploys the runtime of the Windows App SDK it depends on.

[rcohn]

Hi @dimohy -

Many thanks for the quick response.

As regards your comment about V1.1, we are not yet using WindowsAppSDK 1.1, but I wondered if in fact I should be switching over to that version. When we build this unpackaged desktop app, we do not do anything specific to publish other than add <WindowsPackageType>None</WindowsPackageType> to the project configuration. The build copies project artifacts to the bin\x64\Debug\net5.0-windows10.0.19041.0 folder. Our build also installs WindowsAppSDK 1.0 as part of the installation process.

When you say that "it deploys the runtime of the Windows App SDK it depends on", does that mean the app, using the project setting you advise above, will attempt to download the SDK version it needs and install it, or that the app will use what's already installed on the system?

I will be doing more testing over the coming weeks on Windows 11. Since the app must run on both Win 10 and 11, whatever I do has to accommodate both Windows versions - I don't want to have to build two different configurations.

Thanks again.
Best regards,
Robert

[dimohy]

The sentence may be weird because I am not good at English. I ask for your understanding first.

If you create a deployment through 'Publish', the above settings allow you to include runtime for the Windows App SDK. This means that the runtime already installed is not used because it is included in the deployment.

I also have to work well on both Windows 10 and 11, and there is no problem with the setting of <WindowsAppSDKSelfContained> itself.

Of course, since both are included, the distribution is somewhat large.NET runtime and Windows App SDK runtime. But it works fine.

[rcohn]

Hi @dimohy -

So if I understand, by using <WindowsAppSDKSelfContained> , the package will have everything it needs (at the expense of a large package). This will get around problems where the correct .NET runtime and correct WindowsAppSDK are not installed. Everything is there to run the app in the package.

All of this presupposes that the versions of those runtimes work on the target systems. My concern is that the WindowsAppSDK that I was using on Win10 will not work on Win11 (but I have not yet personally tested this - I am going on hearsay).

Anyway, it's good to know that you can bundle everything you need. I will have to try this out and see how large the package is.

Thanks very much, again.
Best regards,
Robert

[rcohn]

Hi @dimohy -

I finally got my hands on a Win11 system and did some testing. First I confirm what you said about using WindowsAppRuntime on a Win11 system. The short answer is that it does work. The long answer is that it seems you must have the exact WindowsAppRuntime version installed that was used to build the app. If I install a later version of WindowsAppRuntime than was used to build the app without having the earlier version installed, then the app does not start up.

This presents a problem. If we go with our present plan of trying to install the (earlier) build version of WindowsAppRuntime and there is already a later version of that runtime on the system, we get an error that indicates the earlier version will not install - and thus the app will not run. Since WindowsAppRuntime can get installed by any app that needs it (including MS Store apps), then our install plan is not going to work.

All of this begs the question of why later versions of WindowsAppRuntime are not compatible with earlier versions (eg, why can an app built with version WindowsAppRuntime 1.0 run when only WindowsAppRuntime 1.1 is installed?)

Anyway, I think that I need to consider your suggestion of using <WindowsAppSDKSelfContained>.

Am I correct in assuming that the resulting package will contain everything I need to run the app - even if that includes an earlier version of WindowsAppRuntime than is currently installed on the system?

Obviously, I can (and will) do some testing on this, but wanted to make sure I'm not overlooking anything.

Thanks very much for your time in answering my questions.

Best regards,
Robert

[DrusTheAxe]

why later versions of WindowsAppRuntime are not compatible with earlier versions

The short answer, because WinAppSDK 1.x defines binary compatibility at the major.minor version. This is spelled out in MSIXPackageVersioning.md section 2.2. Decision 2: Breaking Change Boundary for Version 1.x

why can an app built with version WindowsAppRuntime 1.0 run when only WindowsAppRuntime 1.1 is installed?

Umm, it can't. Apps built with 1.0 require 1.0. The presence of 1.1 on the system is irrelevant to them.

The long answer is that it seems you must have the exact WindowsAppRuntime version installed that was used to build the app.

Not the exact version, just the same major.minor. If you build with release 1.2.3 then at runtime you require 1.2.x where x is >=3. You can run with 1.2.4 or 1.2.888 or... (must be >=1.2.3, not==1.2.3).

Likewise, if you're built with 1.2.3 then no 1.1 release will satisfy you, nor will any 1.3 release.

If we go with our present plan of trying to install the (earlier) build version of WindowsAppRuntime and there is already a later version of that runtime on the system, we get an error that indicates the earlier version will not install - and thus the app will not run.

Could you elaborate? What version is "earlier" and "later"? Are you running e.g. the 1.1.0 installer on a system with 1.1.1 installed and getting errors?

+@sachintaMSFT

[rcohn]

Hi @sachintaMSFT,

Thank you very much for replying to my questions.

What I've found out that if a version of the WindowsAppRuntime (WAR) is installed that is greater than the version built with, then we can't install the version that works with our app. For example, out installer attempts to install WAR 1.0 on a system that has never seen our app. If WAR 1.0.3 is on the system, then we can't install 1.0.

But by your explanation above, the app should run with 1.0.3, so in this case there should not be a problem in being able to run the app. However, if WAR 1.1 is installed, then we would not be able to install 1.0 (or any WAR version that is less than 1.1).

So, the question is really: how do we guarantee that we can always have a version of WAR on the system that is compatible with what we used to build the app?

Again, many thanks for your help.
Best regards,
Robert

[DrusTheAxe]

our installer attempts to install WAR 1.0 on a system that has never seen our app. If WAR 1.0.3 is on the system, then we can't install 1.0.

This has been confirmed as a bug in the installer; fix is underway. For more details see WindowsAppRuntime installation error: The package could not be installed because a higher version of this package is already installed. #2708

However, if WAR 1.1 is installed, then we would not be able to install 1.0 (or any WAR version that is less than 1.1).

Not true. Windows App SDK treats each major.minor release as a uniquely distinct and independent runtime. If you build with 1.0.x you need 1.0.y to run (where y is >=x). But since you built with 1.0 any other major.minor release is irrelevant to you -- 1.1.* is a totally different runtime that won't satisfy your 1.0.x needs. These runtimes include the major.minor release in their package Name so their package families are different -- Microsoft.WindowsAppRuntime.1.0 != Microsoft.WindowsAppRuntime.1.1 != Microsoft.WindowsAppRuntime.1.2 etc. It doesn't matter if the package Names are similar, only if they're identical or not (== vs !=). The 1.0 and 1.1 package names have as much relation to each other as if we named them Fish and Bicycle, which is to say, no relation :-)

The mechanics of this are spelled out in more detail in MSIXPackages.md and in particular in section 3. Package Naming.

Notice how 'Major' and 'Minor' fields are included in the package name. That's why 1.0 and 1.1 are unrelated. That's also why 1.1.3 is a drop-in compatible update for 1.1.2.

Windows App SDK 1.x follows this versioning model. If/when we change that e.g. if we someday say our distinct boundary is only the Major version where 2.1 would be a drop-in compatible update for 2.0 (i.e. build with 2.1.17 and run with 2.x.y where x.y >= 1.17). The mechanics of that would only include the Major version in the package name e.g. Microsoft.WindowsAppRuntime.2 (not Microsoft.WindowsAppRuntime.2.0). But that's a theoretical future. 1.0 and thus all 1.x releases are compatible within their Major.Minor. That's why 1.1 is irrelevant to your app built with 1.0, and why 1.0.* can be installed regardless what 1.1.* packages may be present on the system.

[rcohn]

Thank you for the versioning clarification.

[brandon3343]

if you want to use WindowsAppRuntime 1.0

remove all runtime (when uninstall failed, maybe need to remove some app which use the runtime)

get-appxpackage microsoft.win*app*run* | Remove-AppxPackage

install runtime from microsoft offical site, then everyting is ok

https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/downloads

I had the same problem, and I uninstall VS then reinstall again and again, then It was solved in this way

[rcohn]

Hi -

Thanks very much replying. I do know about the powershell remove-appxpackage, but it's not enough to just remove the package (I found). Also had to remove the DDLM installation (https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/remove-windows-app-sdk-versions)

In my opinion, it's a bug not to allow any version of WindowsAppRuntime to be installed that you need for your app, regardless of what's already installed on the system. I'm not sure, but I think as of 1.1, there is a --force option that will allow this? [Anybody knowledgeable about this, please reply and set me straight if I'm wrong.]

Anyway, thanks again for your help.

[DrusTheAxe]

get-appxpackage microsoft.winapprun* | Remove-AppxPackage

That pattern only matches some of the packages. To match all WinAppSDK packages that should be microsoft*win*apprun* e.g.

get-appxpackage microsoft*win*apprun* | Remove-AppxPackage