[Problem]: UWP App Package for Desktop/Xbox fails Store Certification with Fixed Runtime included

[softworkz]

What happened?

We're building a UWP application with a Fixed Version runtime of WebView2.

The built app bundle fails store certification with the Windows App Certification Kit 10.0.22621.2428 due to use of prohibited APIs by the WebView2 runtime.

[!NOTE] It succeeds when adding the runFullTrust capability but for the simple reason that the 'Supported API Test' is excluded in that case. The APP is meant to be published to the Store for Windows and Xbox, so that's not an option afaiu.

Assets

UWP Store Build

• Package build: https://github.com/softworkz/WebViewDeployment/tree/master/MsixBundles/MSIX_UWP_Default
• Test Report: https://github.com/softworkz/WebViewDeployment/blob/master/MsixBundles/MSIX_UWP_Default/Windows%20App%20Certification%20Kit%20-%20Test%20Results.htm

UWP Build with runFullTrust

• Package build: https://github.com/softworkz/WebViewDeployment/tree/master/MsixBundles/MSIX_UWP_FullTrust
• Test Report: https://github.com/softworkz/WebViewDeployment/blob/master/MsixBundles/MSIX_UWP_FullTrust/Windows%20App%20Certification%20Kit%20-%20Test%20Results.html

Importance

Blocking. My app's basic functions are not working due to this issue.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

119.0.2151.58

SDK Version

1.0.1823.32

Framework

WinUI2/UWP

Operating System

Windows 10, Windows 11, Xbox

OS Version

22621.2506

Repro steps

• Clone this repo: https://github.com/softworkz/WebViewDeployment This is the original Xbox sample with a few changes to get it ready for store publishing.
• Build in Release config and create a package
• Run the generated package in the Windows App Certification Toolkit
• Watch the results

For comparison with runFullTrust:

• Just revert the latest commit or reset to one commit below
• Same steps as above

Ready-built packages and test report are included in the repo in folder ./MsixBundles

[jennifer-jacobs]

Hi @softworkz! We don't support Fixed Runtime for Xbox. Xbox has a validated version of the WV2 runtime pre-installed that stays up to date (similar to the evergreen model on Desktop).

We'll get our documentation updated to make this clearer.

[softworkz]

@jennifer-jacobs - Thanks for the information.

But the problem still stands for UWP desktop, can you please re-open?

[softworkz]

Also, for xbox, how can we make sure that a WebView2 runtime is installed? By the platform version? In that case, which conditions need to be set in the manifest?

Or are we supposed to check this at runtime and display a message like "Oh, sorry, it can't run on your system"?

[nthorn]

Xbox already comes with the WebView2 runtime preinstalled, so you can assume it's there.

[softworkz]

Xbox already comes with the WebView2 runtime preinstalled, so you can assume it's there.

I thought it has just been released? What if somebody didn't update?

[softworkz]

Or is it like that people have no choice and updates are forced? (sorry, I don't know xbox very well)

PS: Shall I open a new issue for non-xbox UWP deployment?

[nthorn]

Xbox system updates become mandatory after a certain amount of time, and the current version does have the WebView2 runtime in it, so you should be good to go there.

I'm not too surprised to hear that a fixed version of WebView2 doesn't pass the UWP certification tests but I can't personally speak to whether that's intended or not.

[champnic]

Reopening for the Desktop certification failure. This sounds similar to #1868, although with different flagged API violations.

Can you try resubmitting? Some devs on that thread reported success after trying again. Can you make sure you have the latest versions of the WebView2 and Microsoft.UI.Xaml SDKs? It looks like you already have a recent Windows SDK. Do you need to use Fixed Version runtime? It's recommended to just use the Evergreen/Installed runtime on Desktop and Xbox. On Desktop the runtime is pre-installed with Windows 11, and has been deployed to nearly every Windows 10 machine, so it's unlikely you'll run into a case where the runtime isn't available.

[softworkz]

Xbox system updates become mandatory after a certain amount of time, and the current version does have the WebView2 runtime in it, so you should be good to go there.

Perfect, thank you very much!

I'm not too surprised to hear that a fixed version of WebView2 doesn't pass the UWP certification tests but I can't personally speak to whether that's intended or not.

Me neither, the docs page on UWP publishing is not really helpful (https://learn.microsoft.com/en-us/microsoft-edge/webview2/how-to/publish-uwp-app-store). It explains the general procedure for app publishing - which is the same as repeated in many other places - but all the information of actual interest and specific to WebView2 is missing.

• It doesn't mention which distribution mode of the runtime is assumed?
  • or recommended?
  • and which are even possible?
• Which trustLevels and appModels (AppContainer or not) are supported?
• It doesn't mention WinUI3 Store apps, does the same apply or what are the differences?

And the few WebView2 related bits are confusing:

Both parts sound like it should be working, and it's stated that no blocking APIs are used. I'm not sure, maybe the article is totally ignoring the runtime distribution and talking about the WebView2Core.dll only?

The distribution of the runtime is the most important and highest-interest topic in this context, because things are very unclear. AFAIK, the evergreen bootstrapper requires elevation, which is a no-go for store apps (to my knowledge), so what remains (and for other reasons) is to distribute with a fixed runtime. As it will be local to the app, there's no elevation required for it. But first of all, it would need to pass the WACK tests.

For WinUI3 it's working fine as WACK doesn't do this test for WinUI3 apps, not even when you choose to run under partialTrust and in AppContainer.

Xbox situation is understood and cleared up - thanks again, now it's only UWP/Windows to address.

[champnic]

@softworkz Great feedback on the documentation! I've opened a separate bug to track improving that. AB#47693677

[softworkz]

Reopening for the Desktop certification failure. This sounds similar to #1868, although with different flagged API violations.

The other issue was about APIs used by the CoreWebView2.dll - this is about the runtime.

Can you try resubmitting? Some devs on that thread reported success after trying again.

I have read those other posts already and I've retested several times with different settings, but the bottom line remains always the same. I haven't submitted it to partner center yet.

Can you make sure you have the latest versions of the WebView2 and Microsoft.UI.Xaml SDKs? It looks like you already have a recent Windows SDK.

Yes, all the latest.

Do you need to use Fixed Version runtime? It's recommended to just use the Evergreen/Installed runtime on Desktop and Xbox. On Desktop the runtime is pre-installed with Windows 11, and has been deployed to nearly every Windows 10 machine, so it's unlikely you'll run into a case where the runtime isn't available.

Unlikely is not good enough. Many of our users have older machines, we have a pretty good picture, because this is a re work of an existing app just with newer tech.

Besides that, we have some requirements for private network access and insecure content (see https://github.com/MicrosoftEdge/WebView2Feedback/issues/4166), and Google is permanently limiting these things. When it happens that a new browser version breaks things, it would be catastrophic as we don't have any time to react. That's why fixed runtime is preferable.

And besides, as mentioned: Doesn't the evergreen bootstrapper require elevation? That's not allowed for a store app, I think, and we really want our app to run after installation and not require users to jump through any hoops...

[softworkz]

The current way how developers are required to deal with distribution matters is not really ideal, so if you don't mind me dreaming for a moment, here's how I think it would be most perfect and convenient (focusing on fixed runtime distribution for this moment).

What's needed?

When developing an app using a fixed runtime, you don't want each developer to go through the process of downloading and putting it in some folder (like it's required now). Also, it's not reasonable to put the runtimes into source control, because a single version with all 3 platforms is about 1.5 GB in size already and it has files which are >100 MB - the file size limit on GitHub. You can use Git LFS (like I did for the demo repo), but over a longer period, this screws version control sooner or later.

Gladly, there's already a very good solution to these kind of problems: NuGet. If the fixed version runtimes would be available as NuGet packages, it would improve the situation a lot.

Ways of Distribution

That satisfies the developer story, but it's not all. The next question is how does the runtime get out to the users of the application, and there are a number of different options. That's nothing new of course, you have those samples in the docs, but it's not really easy and integrated like other MS frameworks/technologies. Now let's look at the options:

Inclusion as Build Content

The most simple way of course - assuming we had those NuGet packages - would be to have the build type for all runtime files set to "Content". This means they will be part of the compilation output and whatever comes after will pick them up:

• A Visual Studio Installer project will take and include them
• ClickOnce will include them
• MSIX packaging will include them

So that's already a pretty convenient way. But it also creates installation bundles of enormous size, so when you are frequently updating the application, this is causing a massive amount of data being moved around and needing to be managed. And most of the updates you have are including the same WebView2 runtimes - again and again, and you need to ship a 500MB package, even though your actual changes might be just a kilobyte for example.

Gladly again, Microsoft has solutions to this for all of its packaging techniques:

MSIX Packaging

MSIX has a concept of dependency packages. A good example for leveraging this is the WindowsAppSDK, and it does exactly what I would be dreaming of when it wouldn't already be there:

• You add the WinAppSdk as a nuget package
• It provides all the files you need during development in your build output
• But when you are packaging your app as MSIX, it prevents those files going into your MSIX package directly
• Instead, it takes care that you magically get this in your packaging output:

It adds itself as a dependency package to the output without adding up to your application package. So, as long as it doesn't change (version), you don't need to re-upload it to the store and users do not need to re-download it when you ship an update - which is then maybe just 10 MB instead of 500 MB

WinAppSdk does that, so it should be easy to adopt.

ClickOnce

ClickOnce has the concept of "InstallationPrerequisites". Having the runtime (and the evergreen bootstrapper) available as prerequisites, would have the same effect in a slightly different way: A prerequisite is downloaded even before your app gets installed or before updating, in case the prerequisite version would have changed.

Visual Studio Installer and WIX

VS installer provides the same "Installation Prerequisite" mechanism like ClickOnce, The primary way of integrating dependencies with Windows Installer (MSI) setups are merge modules (.msm). These are almost the same as MSI, which means that it's easy to build merge modules alongside msi installers for runtime versions.

MSI packages can be used as "Installation Prerequisite". Merge Modules support Visual Studio Installer and WIX - plus almost every commercial and non-commercial installation framework.

Wrapping Up

I know, this sounds like a lot, but the bottom line is: For supporting all typical distribution scenarios in a nice and convenient way, only two things would be needed:

• A NuGet package like WinAppSdk provides
• MSI/MSM packages

It wouldn't take long to get this set up and (of course) automated, so it produces the above automatically each time when a new runtime is released.

Waking Up

Now there's one question remaining - What does it have to do with this issue?

Let's close the loop: If the runtimes would be available as a package like WinAppSdk, then one could have the runtime files in the project for development. But once the app gets packaged for the store, the runtime files don't go into your application package and are instead provided as an MSIX dependency package, which would be managed and submitted to the store by MS itself.

And then - as the runtime files are no longer part of your application package, the package would no longer fail store validation 😄

[softworkz]

Any news on the subject? (fixed runtime shipping with UWP apps)?

Perhaps @KevinLaMS or @DavidShoe have some more insights?

Thanks

[liminzhu]

Late to the thread, there are a lot of good comments and suggestions @softworkz ! First I would definitely still recommend Evergreen to almost all WebView2 developers (I've only seen very few instances where I would recommend Fixed Version usage (e.g. healthcare) and even some of them are moving to Evergreen due to servicing the runtime themselves being a huge pain, so something to consider. Obviously each developer still has their own requirements, so the decision would be up to you. The tradeoff on a high-level -

Evergreen	Fixed Version
lean and have better fundamental characteristics (obviously footprint but even startup speed as often the evergreen dlls would already be in memory because some WV2 app or the hardlinked Edge is already running)	Fairly bulky
Serviced by Microsoft	Developer needs to service it if security matters
Changes between versions; developer can test their app against latest non-stable channels (which is the model web developer follows)	Superior compatibility as the runtime doesn't change from underneath you
On almost all supported Win10+ devices with minor caveats	Developer always needs to distribute their copy

On some of your major concerns on evergreen - 1) compatibility-wise breaking changes are unlikely and developers can test against non-stable Edge channels for future changes but admittedly fixed version doesn't need any of that 2) distribution-wise Evergreen is almost everywhere - they are inboxed on Win11 and we did some push to get them on most Win10 devices. We recommend store developers to check for missing webview2 during runtime and run the installer to cover the corner cases. A lot more details in this doc) so that WebView2 presence is guaranteed. The evergreen installer can be run without elevation. What happens is that without elevation WebView2 is installed per-user, but would be later migrated to per-system by the privileged edge updater. The installer fails if you already have a per-sys webview2 installed. Overall, Evergreen is simpler and more supported in the store configuration.

Hopefully evergreen is a more appealing option now. Diving back to fixed version, I think a non-full-trust fixed version UWP is not something we've looked at before and it's not surprising it'd fail the store validation because it's essentially putting Chromium (which does all sorts of things) into the store. I think getting the fixed version runtime into nuget is useful, but to be very transparent given fixed version usage is very limited and we largely consider fixed versions binaries to be loose binaries that get treated the same as other binaries owned by the developers, I want to set expectations that we're unlikely to prioritize stream-lining it more right now. We might revisit this at a later point. I think the crux of your issue is "how do I get my app into the store", on that I think evergreen is the tried and best option and what we would recommend, but if evergreen is not a convincing option for you we'll follow up with the store team to get further input.

[softworkz]

Hi @liminzhu,

thanks a lot for your explanations. The decision to use a fixed runtime is not made arbitrarily. There are reasons.

One of the problems we are facing is that Google/Chrome is permanently "tightening up" security, but while security is important without doubt, this is also counter-productive with regards to valid use cases. All those changes are driven by the idea that the whole world of software is solely comprised by cloud services and as if one-premises software and use cases wouldn't exist anymore. This leads to ridiculous situations like for example that some remote code from any website with a letsencrypt certifcicate is treated as more secure than html code that comes with an application that a user has installed on his machine from a trusted developer (see my other issue https://github.com/MicrosoftEdge/WebView2Feedback/issues/4166). CORS is surely not a wrong approach in general, but the way that it's implemented without allowing any way to work around it is show-stopping for certain and valid use cases - like accessing our server for personal in-home use, which often isn't even accessible from public network and doesn't have an SSL setup. Now, users must access the client software (served publicly) via http instead of https because when using https, they can no longer connect to their local server (which doesn't have SSL). And the http approach does only work with a Google deprecation trial which ends now and there will be a new API for "private network acccess" which becomes available only a few weeks before the deprecation trial ends. If we hadn't intervened to the latest changes regarding private network access, we would have really gotten into trouble and there wouldn't be a remaining way at all.

Due to that behavior from the side of Google (and MS to an unknown extent), there's a permanent risk that our application might stop working from one day to another, because it could possibly also be some security update which suddenly changes the behavior. When it happens in browsers then it's already a really bad thing, but when we ship an application, then it's not acceptable that it can happen that it stops working from one day to another.

---

I'm already on track of creating such a nuget (framework) package on our own and which includes the runtime as an MSIX dependency package (so the runtime doesn't needs to be included in each update to the actual application). But what remains is the question of how to get it accepted by the store?

Thanks again, sw