Don't make Installer required

[Ciantic]

I just read following phrase:

In the future, your production application should include the installer.

Distributing my app

Have you gauged the interest among developers for that? To me that is a big downside. Why would I want my simple static executables require an installer?

To me ideal distribution method is following: Just use the stable channel Edge user already has installed. If user does not have Edge installed, then the app won't work.

Static self contained executables is the whole reason I want to use webview2 instead of Electron. I package the OS specific logic in the exe and let the webview render the UI. If I need to ask users of the small executable to install something it's not exactly the experience I want.

In many ways the current requirement to drag the DLL with me is also a pain, since I want static executable.

AB#29028418

[bddckr]

That just seems to be under the Evergreen distribution mode section. In the Fixed version distribution mode section it still says

The fixed version distribution mode allows you to select and package a specific version of the WebView2 Runtime.

Does "package" here perhaps mean some static executable/library inclusion? I remember this docs page stating exactly that with more clarity in an earlier version, but perhaps I'm remembering wrong.

It makes sense to me that you cannot expect to distribute a static executable that is kept evergreen.

[Ciantic]

@bddckr "The fixed version distribution mode allows you to select and package a specific version of the WebView2 Runtime."

Do you want to package the runtime with your app? It means you need to ship the runtime with your app, and you are responsible for updating it:

I quote the whole Fixed Runtime passage:

For constrained environments, there are plans to support a fixed version (previously named bring-your-own) distribution mode. The fixed version distribution mode allows you to select and package a specific version of the WebView2 Runtime. The fixed version distribution mode allows you to control which version of the WebView2 Runtime is used by your application, and when user machines are updated. The fixed version distribution mode does not receive any automatic updates, and you should plan to manually apply updates.

If we have to ship runtime (the whole chromium) with the application, and each webview user must update their runtime manually, it defeats the purpose of webview. One could as well use Electron then, no?

We should be able to target stable Edge user already has installed. This is the way webview works in Mac too, one doesn't ship runtime per webview app, and you can write static executables for it just fine.

Indeed, I don't want to have different runtimes of Edge on my machine. It wastes a lot of memory if each webview potentially uses different Edge runtime.

[bddckr]

So I understand now, the issue is about a change to no longer support the only runtime provider a regular user will have in the future: The Edge stable channel. 👍 I'm dumb, whoops. I definitely would like to stay evergreen as part of the user's own Edge update mechanisms and not ship huge binaries myself. Agreed on the point to just go with Electron then (which offers a more mature ecosystem in the first place).

There are multiple channels WebView2 that applications may use as the web platform. By default, WebView2 targets the most stable channel available on the device that meets the minimum version requirement of the WebView2 SDK. The following channels are listed in order from most to least stable channel.

1. WebView2 Runtime (Preview)
2. Microsoft Edge Beta Channel
3. Microsoft Edge Dev Channel
4. Microsoft Edge Canary Channel

The reason is explained in the document:

Microsoft Edge Stable Channel may not be installed on all user machines where your application runs. Instead of requiring that users install Microsoft Edge, your application may use the Evergreen WebView2 Runtime and Installer (Preview). The WebView2 Runtime is a customized copy of the Microsoft Edge binaries that is used to run your WebView2 applications.

---

Fingers crossed the following sentence basically just needs clarification to mean "Once GA is reached the Edge Stable Channel is able to be utilized as the WebView2 Runtime", though it sounds more like

• Edge Chromium might not be installed at all (I'd rather tell my customers to install it than ship and maintain the runtime package).
• You cannot use Edge Stable Channel even once GA is reached, though the Runtime will match what Edge Stable ships, to keep them in sync.

In the future when WebView2 reaches General Availability (GA), the WebView2 Team plans to update the WebView2 Runtime and match the same build as the Microsoft Edge Stable Channel.

[Ciantic]

I hope this installer craze is just temporary until stable Edge ships with the runtime?

I don't know how to interpret all this unfortunately. I just don't want to package my tiny and nice Rust apps with installer. I don't even get it why we have to drag the webview2.dll with us. Can't the DLL come with the stable Edge, and be in known location so we can LoadLibrary it?

The installer part is so exciting to Microsoft that they have drawn a picture for it: https://developer.microsoft.com/en-us/microsoft-edge/webview2/ yet I don't want to have installers for my executables.

[liminzhu]

Sorry for the late reply.

W.r.t. WebView not being able to use Edge Stable, it is a deliberate choice we've made. Let me explain this a little further.

Besides the reasoning stated in the doc, there are also issues on,

1. It is very common for enterprise to have an old version of Edge, usually because they own some intranet sites they need to compat-test on before updating. We'd like for WebView to stay evergreen as much as possible, and using outdated Edge Stable means apps will be on outdated WebView. By separating the binaries, we can let enterprise stay on an older Edge Stable while apps are running on the latest WebView runtime.
2. There will be cases where some last minute issue occur either on the WebView side or on the Edge side, separating the binaries allows one side to update if the issue is only impacting the other side.
3. If we allow WebView to use Edge Stable, we will run into a lot of weird cases. E.g. user does not have Edge Stable first, app needs to install WebView Runtime (the runtime is still necessarily here because in most cases it is not okay for a developer to ask end users to install a browser), and later on Edge Stable get installed, we have to decide if merge runtime and Edge Stable or not, etc. It is not impossible to support these, but there are a lot of ways for both WebView and Edge Stable to get broken by this.

That said,

1. There is consideration to push WebView Runtime to end users through some ways, which hopefully would mean the cases where installer is absolutely necessarily are limited. This has not settled yet, so we cannot promise anything.
2. We will have a fixed version variant for WebView, where you can package all the binaries with your app. In this model WebView will not self-update and will have disk footprint impact (in the evergreen case, all evergreen apps use the same WebView Runtime binaries; for fixed version you own your own copy), just like Electron or CEF.
3. You can also direct your end users to install the WebView runtime themselves rather than packaging it with your app, but that is usually not the best user experience.

[Ciantic]

@liminzhu thank you for your reply.

There is consideration to push WebView Runtime to end users through some ways, which hopefully would mean the cases where installer is absolutely necessarily are limited. This has not settled yet, so we cannot promise anything.

I understand that this is not decided yet, if, and how, and when that is done.

IMO, Webview Runtime must be pushed to stable users of Edge. Otherwise this does not work like webview implementations in other operating systems. Webview users assume it's like a part of OS (or the browser).

Consider projects like this: https://github.com/webview/webview

Implementation, and the upstream projects pretty much assume there is no installer involved. There is already bindings to Rust, Deno, Node etc., and having an installer for each webview application in upstream is not ideal.

[liminzhu]

I agree with your sentiment. The hope on our part (again, please do not take this as a promise) is that,

1. WebView2 gets included inbox in Windows starting a future version. This will basically make WebView2 "work like webview implementations in other operating systems" where you can assume a component is there starting some OS version.
2. The part I said about pushing WebView2 to end users.
3. Over time, enough apps would carry WebView Runtime installer and push WebView to users for us.

And to be clear, even if all these happen, there is no way for us to ever guarantee that every single Windows users automatically get WebView2 (e.g. if we service WebView2 to older versions of Windows through update/patch, there are users who turn that off) and installer is useful in that case. However, you can argue that if you don't want to carry the installer, the risk is much smaller once the runtime becomes more universal.

[rkacharov]

Whatever you decide about distributing, the official and working WebView2 control should be a priority because IE 11 control is no longer supported by a lot of third-party vendors. Therefore, the missing control is a BIG showstopper.

[nothingismagick]

Yeah - I am thinking that at https://github.com/webview/webview we need to become more vigorous about detecting the current state of the system - potentially even shipping a native window informing the user to download the official WebView2. Because right now this all seems very much like a Sisyphus task and it's not very sustainable in the short-term.

[Ciantic]

Not blaming anybody, but I initially thought that the Webview2 already shipped with the stable Edge, using similar reasoning as @LukeOwlclaw here: MicrosoftEdge/WebView2Samples#42 (comment)

Yes, I am using the stable channel. It is currently at 84.0.522.
The release notes for the WebView2 version I am using (0.9.515-prerelease), states:

minimum Microsoft Edge version 84.0.515.0.

So it should work, shouldn't it?

I wouldn't be surprised if others have made this same miscalculation. It was one the reasons I invested time to study this API in the first place.

[liminzhu]

@Ciantic as a thought experiment, before we talk about long-term pushing WebView2 Runtime to end users, would an API that lets you programmatically install WebView2 Runtime be helpful (instead of having to packaging the installer with your app and invoking it in your installer)?

[nothingismagick]

@liminzhu - can't speak for OP, but this would be a fantastic solution for the webview community in my opinion.

[Ciantic]

@liminzhu of course it would help too, it would probably make using the webview/webview easier. The plan would then roughly be to include a function in the webview2 DLL InstallWebView2IfNotInstalled()? It would be called before all the other code is ran, as an initializer of sorts. IMO with all installers, less dialogs, the better, but that little change could make this viable at least.

To me mentally the old plan (as I understood it) was easiest to understand: If you had stable edge, webview2 worked. When Windows 20H1 shipped with stable Edge, I thought this was the time to look at it because it was bundled with Windows. Installer is always extra step compared to that old model.

I wouldn't be surprised if there needs to be multiple ways to distribute this for maximum availability:

1. Push to users of stable Edge, or with certain new Windows OS version.
2. Optional installer triggered by the user of the webview2 DLL, as you suggested (for those who don't have Edge or have old Windows OS).

I actually don't care too much, but packaging with an installer is a problem at least, because that's not how WebView API wrappers like webview/webview work.

[liminzhu]

The idea is quite simple. We planned to release a bootstrapper installer for WebView Runtime (a couple MBs, pulling the RT bits from internet then installing it, in additional to the current stanbdalone all-inclusive 80MB installer). You can either package the bootstrapper with your app, or use a fwlink to download the bootstrapper from our CDN and then invoke installation, which allows you to skip packaging it. The API is basically doing this for you - downloading the installer from fwlink and then installing it, which makes the workflow easier. Obviously this only works for connected devices, offline there is no way around carrying the standalone installer with you.

Having RT inbox and pushing RT to end users is sort of another effort that is being considered, and have a lot of more complexity that affects the timeline.

[Ciantic]

The API is basically doing this for you - downloading the installer from fwlink and then installing it

I assume this is the webview2 DLL API you are talking about. Does it do that automatically or will there be a function? If it does this automatically, then this whole conversation is a bit silly. I'm by no means expert with webview/webview code to say how this affects it. I think @nothingismagick knows it well enough to judge what would be the appropriate behavior for installation, but I suspect something simple like having a function InstallWebView2IfNotInstalled() in the same webview2 DLL that's already required would be simplest.

Only thing I can say out of hand is that packaging the downstream webview apps with installer is not a good solution: Let's say I build "someapp.ts" with webview/webview_deno. It's not viable to expect the someapp.ts be packaged with an installer, because it's just typescript files. What is viable though is that the webview/webview triggers the installation from webview2 DLL function if necessary, if API provides it.

[liminzhu]

It'd be a function. Again, this is a thought experiment to gauge interest, not super fleshed out and designed yet.

webview/webview_deno

This sounds interesting. Not an expert on this, do you have to install deno or something to make it work? Is it packaged with the app?

[Ciantic]

This sounds interesting. Not an expert on this, do you have to install deno or something to make it work?

Well the deno is just an example, you can run deno apps from URLs e.g.:

deno run -A -r --unstable https://deno.land/x/webview/examples/local.ts

(Which is kind of cool and dangerous at the sametime to run native code from URL, but I like it a lot. I can just manage my app in the URL, there is no distribution pains at all, it's just URL.)

I understand that to make it fully fleshed out app if you don't have deno, you'd probably need installer at some point, hence there would packaging. But webview apps are not many times always packaged, like if I build an app with Rust, I just get executable out, there is not installer, it just works.

[bddckr]

I just get executable out, there is not installer, it just works.

This is important to me and makes distribution so much easier nowadays. This is the same with .NET Core - especially with the self-contained deployment model of it there is no need for an installer to begin with.

But the bootstrapper sounds good enough to me compared to an additional API - I have no issue with downloading and running that manually myself in my apps, and I'm sure webview/webview can ultimately handle it the same way. This is assuming there is similar API or a known, never changing registry key or similar, that allows us to query for whether the runtime is already installed, and at which version. Not even having to download the bootstrapper would be great, especially for offline scenarios (I'm fine with telling my users they need to get back online to resolve it with a runtime install).

That said, we all obviously would prefer the inbox distribution, as seen by this issue. If my users disable the inbox distribution I am happy to explain the situation to them and either leave up the manual runtime installation to them, or use the bootstrapper myself for them.

---

Summary/random thoughts/further question:

• It would be highly appreciated that the runtime comes with Windows. Sounds like this discussion and developer engagement is seen as an upvote so to speak 👍
• The bootstrapper seems fine as long as we get stable API that allows us to identify whether we need to run the bootstrapper.
• If the runtime comes with Windows, the ability to disable updates is the same as a customer is able to do for WebView1, right? Or is/was that story different for WebView1? Reason I'm asking: I don't have a single customer on WebView1 that had it disabled and I'm wondering whether this would change at all with WebView2 (in the scenario that it comes with Windows Update).

[liminzhu]

It would be highly appreciated that the runtime comes with Windows. Sounds like this discussion and developer engagement is seen as an upvote so to speak 👍

No doubt this is something we're working towards! I just want to make it clear that until we get this sorted out with Windows folks etc., we shouldn't promise anything :).

The bootstrapper seems fine as long as we get stable API that allows us to identify whether we need to run the bootstrapper.
If the runtime comes with Windows, the ability to disable updates is the same as a customer is able to do for WebView1, right?

The GetAvailableCoreWebView2BrowserVersionString is designed to tell you whether the web platform is there and what version is there. It will go something like this

GetAvailableCoreWebView2BrowserVersionString(nullptr, &versionInfo);
If (versionInfo == null) {
  HResult res = InstallWebViewRuntimeBootstrapper(); // don't have this API yet
  // error handling etc. 
}

I feel like there is a lot of confusion around Runtime, installer, and how to handle all of these. We will definitely make more efforts towards our documentation with more explanation and sample code.

Or is/was that story different for WebView1? Reason I'm asking: I don't have a single customer on WebView1 that had it disabled and I'm wondering whether this would change at all with WebView2 (in the scenario that it comes with Windows Update).

For EdgeHTML WebView, it ships with Windows and gets updated along with Win10. This means no win7, and each version of OS has a different version of WebView. I think once we get WebView2 inbox, the distribution story is at least on par with EdgeHTML WebView (even better, b/c WebView2 gets updated out of band from the OS, so you don't have to deal with different win10 with different WebView2) but it will take time for users to migrate to latest version of win10 and practically unusable for a long while if this is the only thing we do, which is partly why we're doing this installer thing.

[liminzhu]

This is the same with .NET Core - especially with the self-contained deployment model of it there is no need for an installer to begin with.

Oh I forget to point out that we will also have a fixed version mode where you can package the runtime with the application and you don't need to run any form of installer. The downside is that you'd be responsible for the footprint since this is only for your app and not a shared component, and there is no update to fixed version mode (any component that tries to update itself have to go through an installation process). This is essentially how Electron, CEF, and .NET self-contained mode works.

[Symbai]

Oh I forget to point out that we will also have a fixed version mode where you can package the runtime with the application and you don't need to run any form of installer.

The downside is that it heavily bloats up the application size. WebView is just a control and works out of the box. WebView2, as the official replacement, comes with pre-requirements that are not part of Windows by default. This is a huge problem. While previously every developer could embedd IE or Edge, this time the end users will get:

a) Large applications that may be insecure because the developer don't release an update immediatley after a security patch was applied to Chromium Edge.
b) A massive amount of "WebView 2 runtime" installations (because every application is now programmatically installing it). Perhaps even large application startups because it first has to update the runtime, before it can render.

And last but not least, we're back with the issues of silent crashes because a pre-requirement is missing. In .NET, you cannot perform checks if its missing and prompt a messagebox. We would have to go back to native wrappers or native installers which ensure everything is installed before our application launches.

Unless whatever WebView2 requires isn't shipped by default in Windows Update and pre-installed... or embedded into .NET Core runtime... I won't ever switch to it and I'm sure most others won't either. At the current state it causes more troubles than it solves.

[liminzhu]

WebView2, as the official replacement, comes with pre-requirements that are not part of Windows by default.

We are working towards having WebView2 inbox on Windows in the future. The predicament installer trying to solve is that many developers don't want their software to only work on a late version of Windows 10 and onward. For developers who only targets the latest and greatest Windows 10, this is not an issue when WebView2 is inbox.

A massive amount of "WebView 2 runtime" installations

Only the first WebView2 app on the device is installing the runtime. And over time as WebView2 becomes more universal, you will run into less and less cases where installation is needed.

And last but not least, we're back with the issues of silent crashes because a pre-requirement is missing. In .NET, you cannot perform checks if its missing and prompt a messagebox. We would have to go back to native wrappers or native installers which ensure everything is installed before our application launches.

We will provide a regkey to check Runtime presence and version.

[liminzhu]

We are working on improving our runtime documentation, but I want to post relevant information here first since docs may take time.

Premise for WebView Runtime

• Microsoft Edge (browser) is not universal on Windows. It is not pushed to Enterprise users or LTSB/Cs or any Consumer device that turns off windows update and internet. Therefore, Edge browser does not provide sufficient coverage for a lot of WebView2 app developers. We also do not wish to force developers to force end users to install Edge.
• It's not odd for Enterprise to have an outdated version of Edge (assuming they deployed Edge). We want WebView2 to be able to side-by-side with Edge so that Edge can be outdated for compatibility while WebView is evergreen for new features and best security.
• There could last minute issues discovered that only impacts the browser or WebView2 apps. We want the unimpacted party to be able to update while the other side is trying to resolve the issues.

The first premise drive us to make WebView2 Runtime and installer, to allow WebView2 to run in places where Edge isn't there. The other two led us to disallow WebView2 to target Edge Stable directly, so that WebView2 can be evergreen and update separately from Edge. There is on-going effort to include WebView2 Runtime inbox in future versions of Win10, and investigation on whether we can push this to end users downlevel (do not take this as a promise).

For deployment of evergreen WebView2, we are exposing the following (either already exposed or soon)

• A regkey to detect evergreen WebView2 Runtime (RT) presence and version
• [Already in preview] A standalone installer that includes RT bits inside; it can install RT online or offline
• A bootstrapper that is a couple MB in size and when invoked, download RT from internet and install locally. It does not work offnline.
• A fwlink that developer can use to download the bootstrapper.

Note - we will only have per-machine install of RT in the immediate term. This requires elevation to install silently, or end user will see UAC prompt and installer UI. Per-user install of RT is something we plan to look into, assuming developer demand.

The best practice is to check RT presence (using regkey or our API) and install if missing before your app creates WebViews. You can do any of these at install/update time (recommended), or app runtime

• Use the fwlink to download bootstrapper on end user's device and invoke the bootstrapper. This avoids the need to package anything but does not work offline.
• Package the bootstrapper with your app installer/updater or app itself, and invoke the bootstrapper. This only works online but avoids the dependency on our CDN hosting bootstrapper.
• Package the standalone installer with your app installer/updater or app itself, and invoke the installer. This works online/offline and avoids the dependency on our CDN hosting bootstrapper and CDN hosting the RT binaries bootstrapper is downloading from.
• Download the standalone installer, host it on your own CDN, and make your own bootstrapper/fwlink service and use that in your app. This is the most complex, but avoids any dependency on Microsoft CDN while not having to package the large standalone installer.

We will improve our documentation and sample code showcasing some of the workloads (probably not the make-your-own-bootstrapper one) in the coming weeks.

Besides evergreen WebView2, there will also be a fixed version where developers can find WebView2 Runtime in loose binaries form and package the binaries with the app. Developer is responsible to update the binaries. This is similar to how CEF/Electron works.

[antti-j]

Having 90 megabytes evergreen WebView2 Runtime bits in our installer is ok for me. How does this WebView2 Runtime update itself? Will the updates be available through WSUS as the Edge itself?

[ThiloL]

Does Edge Stable not include WebView2 Runtime? Do I have to install and patch ist seperately from Edge?
Are updates available via WSUS? Windows Update and Self-Updating are not possible in our environment.

[antti-j]

Does Edge Stable not include WebView2 Runtime? Do I have to install and patch ist seperately from Edge?
Are updates available via WSUS? Windows Update and Self-Updating are not possible in our environment.

Edge Stable Doesn't include WebView2 Runtime and WebView2 Runtime isn't patched through WSUS. Haven't heard any news about WSUS support since August 2020. See this comment #341 (comment)

[bgxie]

Quote from @liminzhu 16th Dec:

Our SDK is also forward-compatible since v1, so if you're using the current SDK, and never update it while the runtime keeps updating, it keeps working. What I've said applies to Release SDK and the stable APIs in them.

This is really encouraging to hear. It would be great if that could be made clearer in the documentation, e.g. here:
https://docs.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution

There is no reference made to being able to rely on forward compatibility, instead the best practice suggestion to constantly test against newer versions of the Evergreen runtime suggests that Microsoft might be considering to break older APIs in newer versions. The key problem here is to update older software relying on the WebView2 runtime in environments where updates can't be rolled out easily.

[champnic]

@bgxie We'll look at improving the docs. However, we still recommend testing against newer versions not for API compatibility, but for other potential issues. The Evergreen Runtime is always changing along with the web (it's built on Edge Chromium) and while we make every effort to make sure we validate that these changes don't interfere with APIs or other functionality, bugs do sometimes make it to the stable runtime. The sooner we hear about these from partners testing their apps against Canary or Dev, for example, the sooner we can fix the issue before it ships more broadly.

[ftppro]

@champnic Are you for real? This issue was posted nearly a year ago, and now you claim that "The sooner we hear about these from partners testing, the sooner we can fix the issue before it ships more broadly."

It is obvious that it will not "ship more broadly" in the foreseeable future. You are just placating the people who have expressed their annoyance at Microsoft's inaction, which causes even more distrust for Microsoft's development team.

Either give a date when WebView2 will be included with Edge Stable, or admit that this will not happen in the foreseeable future. Stop bullshitting us.

[champnic]

@ftppro Sorry for any confusion I caused you - "ship more broadly" was in reference to the stable runtime getting an update.

[yannduran]

@champnic the level of frustration and dissatisfaction is simply because this whole thing has been handled very badly, and has dragged on for far too long.

[ftppro]

@liminzhu @champnic
To all Microsoft Reps:
The topic of this thread is "Don't make Installer required".
The topic is NOT "Please make my users dependant upon a bloated Runtime that Microsoft can update at any time without the user's permission.".

There are at least 10 posts in this thread from Microsoft Reps, who do not respond to the issue that this thread was created for. Instead, they try to convince developers to use a bloated Runtime.

We do not wish to use a bloated Runtime that Microsoft can update at any time without the user's permission. We wish to know when we can use WebView2 without installing a Runtime component.

Thank you for your consideration.

[bgxie]

@champnic @liminzhu

we still recommend testing against newer versions not for API compatibility, but for other potential issues. [...] bugs do sometimes make it to the stable runtime.

we make every effort to make sure we validate that these changes don't interfere with APIs or other functionality,

Edited, revising my initially shocked reaction, trying to make a business case:

There is an issue with instantiating WebView2 on .NET 4.6.2 as to the published system requirements which was first reported in Feb 17, but despite acknowledgement was not fixed in the next update and hasn't been fixed since. A simple standard test set-up should have caught that, but it was missed twice. See #946

This gives the impression that maybe not every effort is made to guarantee forwards compatibility and, given the comments, that there is an attitude that, since the internet is changing anyway, it is acceptable to occasionally break the runtime or roll out changes that require users to e.g. update their .NET framework, only catering for environments where this is no issue.

But this is not always the case. Being able to build software that can be reliably rolled out in environments that strictly meet the requirements as laid out in the documentation is imperative. That issue #946 has effectively left one of our evaluation clients deployed in a respective environment broken for weeks. The comments made in that thread and this one do not give the impression that there is much urgency in fixing this. Falling back on the fixed version runtime is not a good solution. It doesn't suit many use cases and it would indeed be good if the runtime gets updated to meet changing circumstances.

It would be really important to see commitment by Microsoft to guarantee real best efforts in meeting forwards compatibility. Making this a key point in the documentation and seeing bugs breaking deployed clients fixed immediately would go a long way to instill confidence.

As it is we cannot rely on WebView2 to create stable software.

[ghost]

@ftppro

The squeaky wheel gets the grease:
https://www.bleepingcomputer.com/news/microsoft/microsoft-is-auto-installing-the-windows-10-webview2-runtime/

Edge webview2 should be classified as a "potentially unwanted application" by anti-virus software. I had to uninstall it three times, and it keeps installing itself silently, overriding the official group policy documentation. Perhaps this issue should be mentioned in other popular tools.

[apisarev]

Confusing messages from Microsoft. Can someone please clarify what is the plan, if there is one? If the WebView2 will be distributed with Windows or with Edge?

Mar 2, 2021
Starting next Windows release the WebView2 runtime will ship inbox in Windows, so that covers all future versions of Windows.
https://youtu.be/I_ZBhK9_gTE?t=1328

May 25, 2021
WebView2 is decoupled from the Windows operating system
https://blogs.windows.com/msedgedev/2021/05/25/whats-new-edge-build-2021/

Starting on April 1, 2021, WebView2 Runtime will be installed on devices running Windows and that have Version 2101 or later of Microsoft 365 Apps installed.
https://docs.microsoft.com/en-us/deployoffice/webview2-install

[antti-j]

The evergreen WebView2 runtime is also included with Windows 11

https://blogs.windows.com/windowsdeveloper/2021/06/24/what-windows-11-means-for-developers/

[champnic]

Hey @apisarev - WebView2 Runtime is decoupled from the OS in that it doesn't require a specific version of the OS (Win7+) to run. However, it will be included inbox starting with Windows 11. Office has started using the WebView2 Runtime on Versions 2101+ and so is installing it on machines that don't already have it.

[tomalakgeretkal]

What does "it will be included inbox" mean? I don't recognise this sentence structure. Please clarify.

[champnic]

it will be included inbox

This means when a user installs Windows 11 or buys a Windows 11 machine WebView2 will already be included and won't need to be distributed or installed by your app. Thanks!

[antti-j]

it will be included inbox

This means when a user installs Windows 11 or buys a Windows 11 machine WebView2 will already be included and won't need to be distributed or installed by your app. Thanks!

How WebView2 is updated in Windows 11? Is WSUS supported?

[ThiloLangbeinHUK]

it will be included inbox

This means when a user installs Windows 11 or buys a Windows 11 machine WebView2 will already be included and won't need to be distributed or installed by your app. Thanks!

How WebView2 is updated in Windows 11? Is WSUS supported?

Yes. WSUS is required for domain-joined (enterprise) computers.

[champnic]

The inbox WebView2 will be updated the same way it is today, through the WebView2 updater. Enterprises can disable these updates using policy: https://docs.microsoft.com/en-us/deployedge/microsoft-edge-update-policies#microsoft-edge-webview

I believe we're working on a WSUS solution - @liminzhu may have more details.

[ThiloLangbeinHUK]

@champnic @liminzhu Hopefully WSUS updates are ready not too long after Windows 11 is RTM. :-)

[ThomCBlackwellBSS]

Why can't the WebView control deployment be as simple as the old IE based web control. The current deployment model requires having pretty sophisticated skills with say InstallShield - verifying registry settings, verifying OS's, synchronizing the download and running of the bootstrapper. It really seems like this could be made many orders of magnitude easier. I probably will go back to using Cefsharp (embedded Google chrome) since its NUGET package handles the install process for me by placing the required DLL's into the application's install directory.

[ThomCBlackwellBSS]

What is odd to me is, if you download the NUGET package on the development machine, the WebView control shows up in the Visual Studio toolbox and running in debugging works just fine - so why there is a need to go through all the installer trouble???

[champnic]

Hey @ThomCBlackwellBSS -

Why can't the WebView control deployment be as simple as the old IE based web control.

The old model was tied to the OS. Don't have the right OS? You don't get the web control. In that way, we're similar in that we are being included by default in Windows 11. So if you want to limit your app to Windows 11, you don't need to worry about the installer.

I probably will go back to using Cefsharp (embedded Google chrome) since its NUGET package handles the install process for me by placing the required DLL's into the application's install directory.

Our Nuget doesn't do it automatically, but if you want to include the bits in your application's install directory you can do so using the Fixed Version WebView2 Runtime: https://docs.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution#details-about-the-fixed-version-runtime-distribution-mode Similar to CEFSharp, this version will not keep itself up to date, and you'll need to update it periodically if you want to stay current.

if you download the NUGET package on the development machine, the WebView control shows up in the Visual Studio toolbox and running in debugging works just fine

This is because you have the WebView2 Runtime installed on your development machine. On many other machines the experience will be the same. The problem is that we can't guarantee the WebView2 Runtime is on all machines you may want to run your app on, so we recommend deploying the WV2 Runtime with the installer in those scenarios.

Hope this helps!

[ThomCBlackwellBSS]

Thank you for the quick response! I missed the part where the WebView control will be automatically part of Windows 11 - that is very good for the future. But you are correct - I do have to support Win 10 etc. variants.

I did think about the static version but I did not come across the link you sent me - that helps! I've also put in a support request into InstallShield and if they help out with an example script to use the Evergreen approach I'll be happy to share it.

Again thank you for information and fast reply.

[Optimierungswerfer]

So the earliest Windows version that ships WebView2 inbox is Windows 11? Or are there any plans to also ship it with a future version of Windows 10? In any case, it would be very helpful if this would be documented properly, so that one does not have to search forever to find an (up-to-date) answer to this simple question.

Also, this has quite an impact, because I believe adoption of future Windows 10 versions will stay higher than that of Windows 11 for a good amount of time to come, and if WebView2 can only be relied upon starting in Windows 11 this means developers will need to fall back to dealing with the convoluted installation process of WebView2 for years to come.

Any information on this would be highly appreciated.

[Optimierungswerfer]

This reply answers my question; yes, WebView2 will now also be rolled out on Windows 10.

[champnic]

This is mostly done. We've completed rollout to all Windows 10 machines that we can, are inbox on Windows 11, and no longer support Windows 7 and Windows 8. Going to close this issue, as I don't believe we have any more planned work here.