# OutSystems WebView and embedding Chromium in a .NET desktop app

> The WebView control wraps the CefGlue binding for the Chromium Embedded Framework so a WPF or Avalonia application can host a browser, with typed JavaScript evaluation, synchronous script calls, custom protocols and download tracking on top. The interesting detail is the versioning scheme, which embeds the CEF version in the package number, and the interesting constraint is the platform matrix.

**OutSystems/WebView** — Avalonia/WPF control that wraps CefGlue webview control

- Repository: https://github.com/OutSystems/WebView
- Stars: 601 · Forks: 73
- Language: C#
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/outsystems-webview

## A .NET control over a native Chromium embedding

The WebView control is described in the README as an Avalonia and WPF control that wraps the CefGlue webview control. It is a .NET wrapper control around CefGlue and provides a better and simple API, and like CefGlue it can be used from C# or any other CLR language, with both Avalonia and WPF web browser control implementations.

The problem it solves is specific. Embedding a browser in a .NET desktop application is not a matter of adding a NuGet package. CEF is a native C++ library with its own process model, its own threading rules and its own lifecycle, and CefGlue is the layer that exposes it to the CLR. This project sits one level above that, packaging the result as a XAML control you drop into a window.

The sample projects make that concrete. There is a SampleWebView.Avalonia project in the repository, and the README says to see it for example web browsers built with WebView, noting that it demos some of the available features. A screenshot of the Avalonia sample is included in the README.

The two packages are published on NuGet as WebViewControl-Avalonia and WebViewControl-WPF, and the README says stable binaries are released on NuGet and contain everything you need to embed Chromium in your .NET or CLR application.

The audience is a .NET developer building a desktop tool that needs to show web content, and the people who would otherwise be wiring CefGlue up by hand in every project.

## The platform matrix is the first thing to check

The README publishes a table of operating systems against architectures and UI frameworks, and it is more informative than it looks.

On Windows, x64 and ARM64 are both supported, and both WPF and Avalonia work. On macOS, x64 and ARM64 are supported and Avalonia works, but WPF is not supported. On Linux, x64 is supported, ARM64 works with issues, and again only Avalonia.

The legend distinguishes three states: supported, not supported, and works with issues. Only Linux on ARM64 is in the third state, and the README points to the LINUX.md file in the CefGlue repository for more about the issues and the tested distribution list.

The reason for the WPF gap on macOS and Linux is structural rather than a missing feature. WPF is a Windows-only framework, so the Linux and macOS rows for WPF can never be anything but unsupported, which is why the Avalonia column is the one that carries those platforms.

The last line of that section is the practical constraint: currently only x64 and ARM64 architectures are supported. So the choices are an x64 or ARM64 target, and the WPF column is Windows only.

The repository layout supports this reading, with WebViewControl/ and WebViewControl.Avalonia/ as the two implementations, a SampleWebView.Avalonia/ project, a WebView.sln solution file, and Directory.Build.props and Directory.Packages.props for shared build and package version management.

## What the wrapper adds over a raw CefGlue embedding

The README lists the additional features the control provides, and they cluster around the pain of driving a browser from a managed language.

Strongly-typed JavaScript evaluation is first, where results of JavaScript evaluation return the appropriate type rather than a string you have to parse yourself. That single feature removes the most common source of bugs in this kind of integration, because a number that arrives as text and a number that arrives as a number behave differently downstream and the difference is easy to miss.

Performance is the second concern. Scripts are aggregated and executed in bulk for improved performance, which matters when the alternative is a round trip per call. And there is the ability to evaluate JavaScript synchronously, which is not something you want in general but is occasionally necessary, for instance when a native callback needs a result before it returns.

Then come the behavioural features: JavaScript error handling with call stack information, events to intercept and respond to resources loading, events to track file download progress, the ability to load embedded resources using custom protocols, the ability to disable history navigation, error handling in general, and proxy configuration support.

The proxy support is worth singling out. An embedded browser on a corporate network often has to go through a proxy, and the fact that this is a first-class option in a wrapper control rather than something you patch into the native layer tells you how much real deployment experience went into it.

There is also an option to run in offscreen rendering mode, and the README is candid that it is not recommended as it has several issues.

## The version number tells you which Chromium you ship

The versioning scheme is the most useful thing in the README for anyone planning upgrades.

It works as major, cef_version, patch. The README gives the rules: whenever you fix a bug, increase the patch version, whenever you bring a new feature, increase the major version, and use the minor version for the current cef version.

So the middle number is the CEF version, and the major number is a feature counter rather than a compatibility promise in the usual sense. That is a sensible design for a wrapper whose upstream is Chromium Embedded Framework, because the engine version is what actually determines the browser behaviour your users will see, including security fixes. A library that only tracked its own feature count would leave you unable to answer which Chromium your application is running.

The practical consequence for a consumer is that a major version bump can arrive with a CEF bump underneath it, so an upgrade to a new major version of this control is effectively a browser upgrade, not just an API change. If your application depends on specific browser behaviour, or has an allowlist of certificate authorities and proxy configuration tuned for the current engine, that matters.

The repository has no GitHub releases, so the NuGet versions are the release history, and the two packages, WebViewControl-Avalonia and WebViewControl-WPF, are versioned together.

## What to weigh before you add it

Three things come out of the documentation.

The first is the size of what you are shipping. An embedded CEF browser is a full Chromium distribution inside your installer, and that changes your download size, your disk requirements and your update cadence, because Chromium security updates now arrive on your release train rather than the operating system's. For a tool where the web view is a side panel, that is a poor trade. For a tool where the web view is the product, it is the only option.

The second is the state of the documentation. The README's TODO list has one item, improve documentation, and the documentation is delegated to the sample project. That is a real gap for an API with this many options, and it means reading the source or the sample is part of the evaluation rather than an extra step.

The third is the layering. You are depending on three things: this control, CefGlue, and CEF itself. When something breaks, the question of which layer broke is the first debugging task. The LINUX.md pointer to the tested distribution list exists precisely because the answer is often the operating system rather than the code.

There is also the ecosystem detail that Avalonia FuncUI support is documented, which tells you the control is usable from a functional UI style rather than only from XAML-declared views, and the repository carries a .editorconfig, a Nuget.config and a .github/ directory, the usual conventional tooling for a .NET project that also pulls packages from several feeds.

## Conclusion

OutSystems WebView is a good fit for a .NET desktop team that needs a real browser surface inside a WPF or Avalonia application, because the control handles the CEF native interop and adds the pieces a raw embedding leaves out, namely typed JavaScript results, bulk script execution, download progress events and custom protocol loading. It is a poor fit if you need one codebase to cover WPF on macOS and Linux, because the support matrix rules that out, and a poor fit if a lightweight web surface is enough, since you are shipping a Chromium runtime. Before adopting, check the platform and architecture matrix for the exact target, pin the package version deliberately, because the CEF version in the middle number is what determines the browser engine you ship, and read the LINUX notes in the CefGlue repository for the tested distribution list.

## FAQ

### What is the OutSystems WebView control?

It is an Avalonia and WPF control that wraps the CefGlue webview control so Chromium can be embedded in a .NET or CLR application, usable from C# or any other CLR language. The packages are published on NuGet as WebViewControl-Avalonia and WebViewControl-WPF.

### Which operating systems and architectures does the WebView control support?

The README table shows x64 and ARM64 on Windows with both WPF and Avalonia, x64 and ARM64 on macOS with Avalonia only, and x64 on Linux with Avalonia, where ARM64 works with issues. Only x64 and ARM64 architectures are supported.

### How does the WebView versioning scheme work?

It is major, cef_version, patch. The minor position carries the current CEF version, a bug fix bumps the patch version, and a new feature bumps the major version, so the package number tells you which Chromium your application ships.

### What does the WebView control add on top of CefGlue?

The README lists strongly-typed JavaScript evaluation, bulk script execution for performance, synchronous JavaScript evaluation, JavaScript error handling with call stack information, events to intercept resource loading, download progress events, loading embedded resources through custom protocols, the ability to disable history navigation, error handling, proxy configuration support, and an offscreen rendering option.

## Sources

- [Issues](https://github.com/OutSystems/WebView/issues)
- [License: Apache-2.0](https://github.com/OutSystems/WebView/blob/master/LICENSE)
- [OutSystems/WebView on GitHub](https://github.com/OutSystems/WebView)
- [README](https://github.com/OutSystems/WebView/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/outsystems-webview