Choosing between DotNetBrowser and WebView2
Originally posted in DotNetBrowser Blog.
In .NET, when you need browser control, you don’t get to choose the engine anymore. The unfortunate retirement of embedded Gecko and Trident leaves you only with Chromium. Fortunately, the variety of Chromium-based solutions makes up for the lack of choice in browser engines. Our goal is to help you choose what fits you better.
In the previous article, we compare open-source CefSharp with DotNetBrowser.
Today, we explore proprietary WebView2 and argue that DotNetBrowser is a better fit for commercial use. We start with the organizational and legal aspects. After that, we cover the functional differences.
TLDR
DotNetBrowser and WebView2 are mature solutions from commercial companies with considerable experience in this area. So, you get a software solution that works and doesn’t depend on the open-source community.
Choose WebView2 when:
- You have to use free software.
- You want to use the perks of the evergreen distribution.
- You don’t mind sharing the end user’s data with Microsoft.
Choose DotNetBrowser when:
- You want to get assistance with product use.
- You want to report issues confidentially and have them fixed.
- You need a custom feature.
- You want to have control over the end user’s data collection.
- You need to run the application without UI.
- You need to print programmatically.
Introduction
WebView2 is a control from Microsoft. It’s free, but — as one expects from Microsoft — it’s also proprietary. It comes as a replacement for a Trident-based WebView and uses Edge instead.
WebView2 is a control: an item in the Visual Studio toolbox, classes from the Microsoft.Web.WebView2.Core.dll file. But it is not a Microsoft product like Office or PowerBI. So, no customer care, technical support, or assistance is included.
DotNetBrowser is a product created and developed by TeamDev, a company specializing in browser embedding. We started with Internet Explorer in 2004 and continued with Safari and WebKit later, and eventually, we settled down to Chromium in 2013.
In 2015, we introduced DotNetBrowser. It is a commercial product designed for commercial use. Besides the software and documentation, the offer includes a dedicated Customer Care specialist, technical support, and premium services.
Fixes, Features, and Assistance
No software is perfect. Take any library in the world, and you will find that it lacks just the feature you need. And after that, you will discover a bug that blocks your release. And to work around this bug, you will need to use functionality that documentation doesn’t cover particularly well.
How do you get help in this unpleasant but common situation? Let’s take a look at what WebView2 and DotNetBrowser have to offer.
WebView2 gathers feedback from the public in a dedicated GitHub repository. When you have a question or something to report, you create an issue there. If developers from Microsoft find your report worthy, they will transfer it to their internal system. You will know by their “tracked” label for such issues.
Microsoft developers react quickly to new reports, but it doesn’t correlate with how quickly they resolve them. For example, almost 80% of tracked issues stayed unresolved for more than six months at the moment of writing.
DotNetBrowser has a private helpdesk system where reports from clients remain confidential. The guaranteed first response time or SLA is one business day.
The technical support includes help with product use, assistance with troubleshooting, bug fixing, and considering feature requests. All your support requests will be processed by DotNetBrowser software engineers.
Privacy of End Users
This article was written in November 2022 and described the version of EULA as of this date.
When an end user installs WebView2 in their environment, the installer shows them EULA. Two things may concern you:
- Microsoft may collect information about your end users.
- You’re required to warn them about it.
Section 3.a of the EULA states that WebView2 may collect information about you and the end user’s use of the software. This information is then can be sent to Microsoft.
The fact that Microsoft gathers the end user’s information obliges you to show the corresponding notice and get their consent (Section 9 of the EULA).
DotNetBrowser does not collect information about you and your end users. Furthermore, it prevents data collection by Google. Read more about how DotNetBrowser handles data and gives you control over privacy in the Privacy Practices.
From a technical standpoint, DotNetBrowser and WebView2 are not that different. Both have similar architectures where Chromium runs in a separate process. Both have hundreds of features, most of which overlap.
The differences, however, exist. And they can be essential when choosing the solution that fits your case. So, let’s take a look.
Distribution and Deployment
You may bring WebView2 Runtime with your application or use the one installed at the end user’s. These are distribution modes: the fixed version and the evergreen, respectively.
With the fixed version mode, you control the version of WebView2 in your application, which is good for stability. While in the evergreen mode, you let Microsoft take care of the logistics and updates and reduce the size of your software. The official documentation does a great job explaining all pros and cons.
DotNetBrowser needs to be packaged with your application. It is the only distribution mode that comes out of the box.
Chrome Extensions
Support for Chrome extensions is a popular request among DotNetBrowser clients. WebView2 users want it too.
DotNetBrowser supports Chrome extensions, it’s in a public preview. Check out the blog post where we explain how to use it.
In the WebView2 repository, the requests for extensions are labeled as tracked. In 2021, Microsoft developers mentioned working on this feature and asked the community some follow-up questions. Since then, no updates.
Running Without UI
For use cases such as automation or generating PDF reports, it’s unnecessary to have a user interface. Instead, it’s simpler and more efficient to run headless.
WebView2 doesn’t support running without UI, as it requires an application window.
In DotNetBrowser, this works out of the box. You can use it in the console application, on the web server, or even as a Windows service. Just like this:
Linux and macOS Support
According to the roadmap, WebView2 plans to support macOS and, later, Linux. While they don’t disclose estimates for Linux, it seems that macOS support will be ready in 2023.
DotNetBrowser is a cross-platform library that runs on Windows, macOS, and Linux. Use it with Avalonia UI or in the server application.
WPF and Overlapping Controls
Putting any WPF control on top of a WebView2 control is impossible. This is caused by the natural WPF limitations and how WebView2 works.
WPF doesn’t support overlapping between regions rendered in different windows, and WebView2 works precisely by embedding a foreign window into WPF control.
For DotNetBrowser, this is not a problem. Besides using the native window like WebView2, it can render directly within the WPF window.
It’s called the off-screen rendering mode. In this mode, the rendered pixels are copied to the .NET process memory and displayed in a regular WPF widget.
Calling JavaScript From .NET
In both solutions, you can execute JavaScript right from the .NET code. The difference is in what happens when the result travels back from Chromium to the .NET world.
WebView2 converts the result to JSON:
DotNetBrowser automatically converts simple types. It replaces the complex types with proxies to actual V8 objects:
Calling .NET From JavaScript
Both solutions allow using .NET objects from within JavaScript, but with a catch.
In WebView2, an injected object should be COM visible and implement IDispatch. This requirement limits the range of what you can inject and multiplies the boilerplate code.
In DotNetBrowser, you can inject anything: standard .NET objects, collections, and even WPF controls. In JavaScript, you will have access to the injected object’s public members and indexed properties.
Intercepting Traffic
WebView2 doesn’t have an API for intercepting, filtering, or modifying HTTP requests.
DotNetBrowser, on the other hand, has a broad functionality for managing HTTP traffic. With this functionality, you can implement the following:
- Filtering out requests and redirecting them to custom URLs.
- Overriding the HTTP request and response headers.
- Overriding request upload data.
- Intercepting response data, including AJAX requests.
- Filtering out cookies that should be set for the client or sent to the server.
Printing API
WebView2 has a limited printing API. It can print to PDF and allows you to manipulate a handful of settings. Alas, it is pretty limited:
- You can’t choose a specific system printer.
- You can’t configure page ranges.
- You can’t control printing dialogs displayed to the user.
DotNetBrowser provides complete control over the printing process. You can:
- Choose a printer.
- Handle printing initiated by JavaScript and .NET code.
- Seeing the capabilities of a printer to avoid using unsupported features.
- Configure print settings, including page ranges, paper size, margins, headers, footers, etc.
Please feel free to try out DotNetBrowser for free during a 30-day trial. And if you have any questions about using the library, don't hesitate to contact us. We will be happy to assist!
