Closed ftppro closed 1 year ago
Hey @ftppro - You might want to look at the WebView2 Runtime Installer and see if that suits your needs better: https://docs.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution#understand-the-webview2-runtime-and-installer-preview When this releases this will be the main long-term solution for distributing WebView2 support.
Another option if your current users are willing to download Edge, is they can use the Dev or Beta channels as well, which update on a weekly and 6-week cadence. You just have to be careful of your SDK versioning, as these channel build versions are older than canary.
The WebView2 Runtime Installer is 88MB, so that is not feasible. I also don't want to worry about strange things that can happen during the installation of such a large file. I would rather have the user perform the installation from a Microsoft website.
What is the projected date that the WebView2 control will be included with the default version of Edge?
Which version of the WebView2 control is currently in the Beta Channel (and how can I see that info)?
If the WebView2 control works with the Beta Channel (the "most stable" channel), then why does all the documentation insist that the Canary Channel is a "prerequisite", even though the Canary Channel is the least stable?
The WebView2 Runtime Installer is 88MB, so that is not feasible. I also don't want to worry about strange things that can happen during the installation of such a large file. I would rather have the user perform the installation from a Microsoft website.
We will also expose a small bootstrapper. That would be a few MBs instead of the full 80MBs and will grab the WebView2 Runtime through internet connection when invoked.
What is the projected date that the WebView2 control will be included with the default version of Edge?
We don't have any plan yet to include WebView with Edge Stable. This thread has the details.
Which version of the WebView2 control is currently in the Beta Channel (and how can I see that info)?
Versioning is hopefully helpful.
If the WebView2 control works with the Beta Channel (the "most stable" channel), then why does all the documentation insist that the Canary Channel is a "prerequisite", even though the Canary Channel is the least stable?
WebView2 Runtime will be the most stable channel once we GA. During preview, our guides recommend the Canary channel because we usually ship SDKs when they only work with Canary. It takes some time for the same support to go from Canary to Dev/Beta/WebView2 Runtime.
I don't want to use the Runtime, since it has too much potential for problems. Until WebView2 works with the current version of Edge, I would rather require that users install one of the Channels from the Microsoft website.
I don't want to use the Runtime, since it has too much potential for problems.
I'd love to understand your concern here. Is this about that the Runtime is new and a relatively unknown entity, or that it requires you do perform extra packaging and installation? The Runtime in many ways is just Edge Stable with a little modification and the platform is more stable and robust than Beta. If latter is the core concern, it might be better to ask end users to download the runtime instead of Edge Beta since Beta will be less tested than Runtime.
Other questions are as @champnic mentioned.
When will the current Beta version become Edge Stable? When that happens, will WebView2 v.0.9.515-prerelease then work with the current version of Edge? Then, instead of requiring that users install the Beta Channel (or requiring that my program performs a "Runtime" installation), I can just require that the user has the current version of Edge.
No - we don't support the Edge Stable channel at all. Some reason why are described here: https://github.com/MicrosoftEdge/WebViewFeedback/issues/341#issuecomment-662719106
We hope to be available on most machines in the future, which Limin describes here: https://github.com/MicrosoftEdge/WebViewFeedback/issues/341#issuecomment-663269255
Isn't the Beta Channel the next version that will become Edge Stable? If the Beta Channel allows the usage of WebView2 v.0.9.515-prerelease, then wouldn't Edge Stable also allow that usage when it is copied from the Beta Channel? It are these discrepancies that make me very leery to have my app install the Runtime component.
I was previously told that WebView2 v.0.9.538-prerelease will not work with the Beta Channel. However, I uninstalled the Canary Channel and installed the Beta Channel, and my app which uses WebView2 v.0.9.538-prerelease appears to work fine. What situation will I encounter with the Beta Channel that will force me to downgrade to 0.9.515-prerelease? If there is no such situation, then it makes sense to not use the older version of WebView2, and to advise users of my app to download the most stable version (Beta) instead of Canary, right? Am I missing anything?
When using an SDK with any channel, you need to make sure that the SDK version is not ahead of the current channel version: https://docs.microsoft.com/en-us/microsoft-edge/webview2/concepts/versioning
Some things may work, but others will be broken. It depends what's changed and what you are using, but highly recommended to use the supported SDK package.
Whether things will work or not depends on how much change happened to our COM interface definitions. For example, your 538 SDK code may be thinking it's calling a function in the WebView dlls, but in actuality it's calling a different function because a difference in the interfaces is causing a mismatch. In this instances, sometimes stuff just works, sometimes stuff breaks or behaves slightly weird, and sometimes stuff crashes.
For the question about stablechannel, it's not a matter of whether it would theoretically work or be compatible - our code explicitly disallows using the stable build. Right now the runtime is in preview, but when it GAs it will be based on the stable channel and be the recommended and most stable WebView2 experience, and the one we recommend for end-users. Part of the problem right now is that none of our controls have GA'd, and we don't recommend shipping to end-users at all yet.
Here's some info on distributing apps with WebView2: https://docs.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution Here's a brief outline of our desired ship schedule (but not promises), including the runtime and .NET support: https://docs.microsoft.com/en-us/microsoft-edge/webview2/roadmap
This page shows that WebView2/0.9.538 was last updated 2 months ago: https://www.nuget.org/packages/Microsoft.Web.WebView2/0.9.538
This page shows that the Beta Channel is updated every 6 weeks: https://www.microsoftedgeinsider.com/en-us/download
Therefore, can I assume that the Beta Channel will "catch up" to WebView2 0.9.538, and be compatible with it in the next several weeks?
Also, please answer these questions:
I am not interested in having my app install the Runtime component, so please don't answer my questions by suggesting that is what I should do. Instead, I want to require that users of my app install a particular version of Edge that they download from a Microsoft website.
No worries, you can use Beta, I just want to make sure you understand the versioning restrictions with the SDK.
It looks like the next Beta, which will have version 564 and be compatible with SDK 538 and 538-prerelease, is slated to ship within the next week. The current Beta (522) became Stable (522) about a week ago.
We are revisiting this policy of not allowing Stable, but I can't make any promises. We are certainly taking your feedback into account here, and I understand your frustration at not being able to use the Stable channel.
1 Which webpage shows the current version of the Beta Channel?
When I display the Help/About on the version of Beta that I just installed, it shows version 84.0.522.39. You said the next version of Beta will have version 564. That doesn't seem to follow the version numbering system. What version will be shown on Beta's Help/About when it is compatible with WebView2/0.9.538, and will that update happen automatically when I display Help/About?
Sorry, the full version of the next Beta will be something like 85.0.564.n, and will be compatible with SDK 0.9.538. The important part when working with WebView2 SDKs is the 564, as that Edge/Runtime version needs to be greater than the SDK version to be compatible. For example: Edge version (any channel) 84.0.522.n is compatible with SDK 0.9.515, because 522 > 515. Edge version (any channel) 84.0.522.n is NOT compatible with SDK 0.9.538, because 522 < 538.
Beta will automatically update to that version, and when it does (in about a week), you will see the version number update in Help/About.
Edge Beta is now version 85.0.564.18, which means I can safely use WebView2 v.0.9.538-prerelease in my app without requiring Canary, right? My users will feel more comfortable installing Beta instead of Canary, since it is shown as "the most stable Microsoft Edge preview experience." Now please convince the powers-that-be to include WebView2 in Edge Stable, so my users won't have to download anything other than my app.
Yup, they can use Beta! The convincing has begun :)
In the meantime, we're looking at a potential option that would lessen the burden on app developers and not require you to ship an installer. Instead, we would have the loader (webview2loader.dll - no extra work on your part), which you are already shipping in your app:
Do you think this would help your situation? Would it solve your situation?
One benefit is that this would allow you to run your app in places where there is no Edge Stable currently installed. One drawback is having to have the users accept the install when they first use your app. (Note: This would only affect the first WebView app on the machine - once the Runtime is installed once all WebView apps would be able to use it)
That seems to have more potential problems than just asking the user to install Edge Beta from the Microsoft website..
Can you expand on what potential problems you'll think we'll run into? Or are you concerned it will just be buggy?
It's an issue of liability. If my app downloads and runs the runtime installer, I have more liability than if I require that the user installs Edge Beta from the Microsoft website. Particularly because Edge Beta is shown as "the most stable Microsoft Edge preview experience." I don't know how thoroughly the runtime installer is tested, or what version of the runtime installer my app would be downloading and installing, so it is too risky.
Ah, gotcha.
For WebView2 apps, the runtime will be the most tested and most stable solution.
The runtime is based on the Edge Stable channel (which itself is more stable than Beta). There is very very little differentiating the runtime from the Edge Stable build. However, it's possible that there's a version of Edge Stable that gets shipped with a bug that affects WebView. The Edge team is unlikely to block releasing Edge Stable because of a bug that only affects the WebView, meaning that when Edge Stable gets released, any WebView apps relying on it would break in some way. The runtime gives us the ability to say "This version of Edge Stable is breaking a lot of WebView apps, so let's not release a runtime version of it.", avoiding the breaking bug.
I released two apps that use the WebView2 control, and a unanimous consensus indicated that very few people will install Edge Beta just to use an app.
For the reasons that I described in my previous replies to this post, I absolutely do not want to have my app install a runtime installer, so please do not reply with that suggestion again.
I read the reasons that Microsoft has not added WebView2 functionality in Edge Stable, and those reasons make no sense. One excuse they gave was that the WebView2 control will not work if the user does not have the current version of Edge Stable installed. That excuse is ludicrous. That's like saying Edge should not support HTML5, because someone with an older version of Edge may not be able to use HTML 5.
It is a shame that the WebView2 control cannot be used for a production app, and its only purpose at this time is for experimentation. The old WebBrowser control in Visual Studio is now completely obsolete. It is a huge deficiency that Microsoft is currently not offering any method to embed a browser in a production app, other than asking the developer to have their app install a runtime installer, which is unacceptable.
🤦♂️
@ftppro The WebBrowser control is not obsolete, it still has many uses to display user content. MS does have a roadmap for supporting WebView2, but it's currently pre-release so of course it's not part of any stable release.
I am okay with WebView2 connecting to the runtime IF Microsoft pushes the runtime out to Windows 8 and 10 via Windows update. I'd prefer to not bundle the WebView2 runtime installer with my apps just to display web content. They aren't concerned with pushing Edge Chromium via Windows Update, so I can't see why they wouldn't just do that with the runtime too. Otherwise the loader should connect to whatever it can find... the runtime first... Edge Stable second, then beta, then canary (unless otherwise specified in the app). Leaving Edge stable out of the list of things it can connect to is just nutty, but if they insist on doing that they had better push the runtime via Windows update and not make us distribute it with our apps.
Does Microsoft have some legal agreement with Google that permits it from adding Chromium functionality to Visual Studio, thus preventing them from adding WebView2 functionality to Edge Stable?
I can't think of any other reason for this limitation, which makes a Chrome Extension the only method by which a programmer can have an app access a website's rendered content.
As I previously described, it is not feasible to require that an app user downloads Edge Beta or a runtime component.
This is a huge limitation of Visual Studio.
Just my two cents, the new Edge has already been pushed out to Windows 7 and greater. Once the release version catches up to the required version for the SDK all of this will be a mute point.
Just my two cents, the new Edge has already been pushed out to Windows 7 and greater. Once the release version catches up to the required version for the SDK all of this will be a mute point.
No, because it sounds like they won't be allowing it to use the Edge Stable channel (which is what has been pushed out) ... it will only use the runtime or the beta or other unstable versions. I am asking them to allow it to use the Edge Stable channel OR push out the runtime to all those platforms.
Intentional or not, I was able to pass the path of my stable install to the ...WithOptions variation and it worked fine.
Intentional or not, I was able to pass the path of my stable install to the ...WithOptions variation and it worked fine.
If that works I suppose a potential workaround could be, try with the default search path and if it doesn't find a compatible Edge, then pass the default path to Edge Stable and see if that works.
The version of WebView2Loader.dll I used was 0.9.579.0 as an FYI.
@kczx3 are you saying we are able to use CreateCoreWebView2EnvironmentWithOptions
and pass it the path to the Edge installation folder as browserExecutableFolder
and it will work without WebView2 Runtime Installer?
@kczx3 @nmoinvaz I'm wondering the same as kczx3. These comments are very confusing. It would be very hopeful if a qualified Microsoft rep could clarify this issue. What is the estimated date that we will be able to add a WebView2 control to a Windows Form app, without requiring that the app execute a runtime installer, or requiring that the end user downloads Edge Beta?
@kczx3 are you saying we are able to use
CreateCoreWebView2EnvironmentWithOptions
and pass it the path to the Edge installation folder asbrowserExecutableFolder
and it will work without WebView2 Runtime Installer?
Yes, that’s what I’m saying. Try it for yourself...
@kczx3 Have you tested this theory after removing all other versions of Edge from the machine, except the default Edge that is installed with Windows 10?
I confirmed it was using the stable version by launching the dev tools of the webview2 and checking the version
@kczx3 You didn't answer my question. Have you tested this theory after removing all other versions of Edge from the machine, except the default Edge that is installed with Windows 10? I doubt your solution, because every Microsoft rep insists that WebView2 requires that the Beta version of Edge is installed, or the runtime installer is used. They would have proposed your solution if it worked. As they stated on July 29: "We don't have any plan yet to include WebView with Edge Stable. This thread has the details: https://github.com/MicrosoftEdge/WebView2Feedback/issues/341#issuecomment-662719106
Frankly, I don't know that I care to continue having a conversation with you.
@ftppro FYI, you may not know, but you can seem quite rude.
Can a Microsoft rep please confirm that the solution proposed by @kczx3 entirely eliminates the need to either install the Beta version of Edge, or perform the runtime installer, to utilize all the features of WebView2? I'm sure that other developers also want to be certain that this solution is not erroneous. Otherwise, they could waste a lot of time releasing an app that fails to run on a new Windows 10 machine.
Hey all, @kczx3 I believe this is working for you because you are on 0.9.579-prerelease. I'm relatively certain we removed that behavior in a later SDK. If it is still working, I wouldn't rely on it as it's unsupported and could stop working with an update to the SDK or runtime.
Details on distribution are here: https://docs.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution I know this is currently a complex story that we are looking to improve, and so if that doc is confusing or you have questions about it please let me know. We are also hoping to streamline deployment to make it as easy as specifying .NET frameworks. We are also pursuing getting the runtime inbox and deploying to downlevel OSs. Thanks!
The version of WebView2Loader.dll I used was 0.9.579.0 as an FYI.
I have not tried with this version, but I have been unable to get it to use the stable Edge with 1.0.622.22 or 0.9.622.11 ... but looking in the Edge Stable folder the webview2 DLLs are present. I think they may have blacklisted Edge stable via this method in the newer releases.
It makes sense when checking the documentation of the different versions.
Here a quote from version 0.9.579 about the browserExecutableFolder:
"The default channel search order is stable, beta, dev, and canary."
and here from version 1.0.622.22:
"The default channel search order is the WebView2 Runtime, Beta, Dev, and Canary."
Additionally there is this interesting note in the new documentation:
The path of fixed version of the WebView2 Runtime should not contain \Edge\Application. When such a path is used, the API will fail with ERROR_NOT_SUPPORTED.
And as 'msedgewebview2.exe' is already there in the stable Edge version the only limitations of not using it, is probably the '\Edge\Application\' in the path-name.
This allows a dirty workaround/hack to use Edge stable without installing the Webview2 runtime: Copy the whole "C:\Program Files (x86)\Microsoft\Edge\Application\86.0.622.48" folder to a temporary folder and use that folder as browserExecutableFolder path - AND - surprisingly Webview2 works on systems that only have the Edge stable installed! ;-) (and that folder duplicating is faster and more silent than downloading and running the Webview2 Runtime installer)
So my wish - please remove that path limitation and let the developers use Edge stable! Otherwise such hacks might been seen soon in the wild!
@champnic ahhhhh ok, thanks for that! I knew it was working at one point but couldn't get it to work today when I was trying.
This allows a dirty workaround/hack to use Edge stable without installing the Webview2 runtime: Copy the whole "C:\Program Files (x86)\Microsoft\Edge\Application\86.0.622.48" folder to a temporary folder and use that folder as browserExecutableFolder path - AND - surprisingly Webview2 works on systems that only have the Edge stable installed!
If it is really just the path name that is causing it to error out, I wonder if a symbolic link with CreateSymbolicLink() to the Edge Stable Application directory would allow it to work.
Hi folks,
Just want to re-iterate a few points here. Not allowing Edge Stable to work with WebView2 is a conscious and careful decision on our end, some details are in Understanding the WebView2 Runtime. Some important points,
Something that could REALLY help us is to let us know the rationale on why you want Edge Stable and why the programmatic workflows (we are not suggesting end users to manually download stuff as it'd be bad user experience in most cases) in Deploying the Evergreen WebView2 Runtime is not working well for you. For example, if you programmatically download the Runtime Bootstrapper on user device using the link we provide and invoke the installation, you don't actually need to package anything and you can potentially do this as a part of your app first launch rather during app installation if your app doesn't have an installer. This would help us better judge the situation and motivation, and build a better product.
Now in terms of some of the ways to use Edge Stable on the thread, since we're not supporting Edge Stable w/ WebView2 right now, we cannot guarantee these will always work or be responsible for any breaks. A good example is that Edge Stable is not guaranteed to always be installed at the same spot.
Many people are reluctant to download the Canary Channel, because the download page states that it is "Updated daily".
Until the WebView2 control is included with the version of Edge that is automatically updated by Windows Update, it will be difficult to convince people to download the Canary Channel, which is currently a requirement.
When will the WebView2 control be included with the default version of Edge, so developers won't have to convince people to download the Canary Channel?
AB#29028418