**Updated** for 2020, I&#39;ve [linked my article](https://dev.to/noseratio/comparing-process-working-sets-of-webview-based-windows-desktop-apps-5dkk) where I compare the memory footprints of different approaches to hosting HTML WebView in a basic Windows Desktop application:

- [MSEdge WebView2 WPF](https://github.com/noseratio/CompareWebViews/tree/main/WebView2App)
- [Chromely/CefSharp](https://github.com/noseratio/CompareWebViews/tree/main/ChromelyApp) 
- [Electron v10](https://github.com/noseratio/CompareWebViews/tree/main/ElectronApp)
- [Legacy IE11 WebBrowser WPF](https://github.com/noseratio/CompareWebViews/tree/main/IE11WebBrowserApp).

&lt;hr&gt;

Internet Explorer-based WPF WebBrowser control suffers from some [keyboard and focus issues][1] and [memory leak issues][2]. As an alternative solution to these problems, we&#39;re considering available options for hosting Chromium instead of WebBrowser control in our WPF/C# project based around HTML editing. Similar questions have been [asked][3] here previously. I&#39;ve read the answers and done my own research, **but I hope to obtain some more feedback from people who have actually used any of the following options in production-quality projects**:

[Awesomium][4] and [Awesomium.NET][5]

It looks very appropriate, but I don&#39;t like the fact the project is not open-source and the full source is not easily available. Also, it might be an overkill for our project, as off-screen rendering is not something we really depend on.

[Chromium Embedded Framework (CEF)][6] and [.NET bindings for CEF][7]

This is probably the best option currently available. The project seems to be alive and active, being currently in sync with Chrome v27. CEF3 uses Chrome multi-process architecture. It also looks like Adobe is giving it [some endorsement][8]. 

[Google&#39;s Chrome Frame][9]

While the original purpose of it was to be an HTML5 plugin for IE and Firefox, it actually works as standalone ActiveX control too, so I could wrap it for use with WPF. It exposes a [sufficient API][10] for interaction with the inner web page (`onmessage, addEventListener/removeEventListener, postMessage`).
I&#39;m aware Google is to [discontinue][11] Chrome Frame, but I assume the sources will remain in Chromium repository. It should not be difficult to update it with the latest Chromium code as we go, and we would have full control over this.

[WebKit .NET wrapper][12]

Not exactly Chromium-based and doesn&#39;t use V8 engine, so it is not really an option.

Is there any other option I might have overlooked? 

**I would greatly appreciate if someone shared her/his experience with any of the above options for a real-life, production-quality WPF project. Did you have any integration, licensing, or deployment implications?**


  [1]: https://stackoverflow.com/questions/18256886/webbrowser-control-keyboard-and-focus-behavior
  [2]: https://stackoverflow.com/questions/8302933/how-to-get-around-the-memory-leak-in-the-net-webbrowser-control
  [3]: https://stackoverflow.com/questions/790542/replacing-net-webbrowser-control-with-a-better-browser-like-chrome
  [4]: http://awesomium.com/
  [5]: http://awesomium.codeplex.com/
  [6]: https://bitbucket.org/chromiumembedded/cef
  [7]: https://github.com/cefsharp/CefSharp
  [8]: http://www.google.com/search?q=%22Chromium%20Embedded%20Framework%22%20site:adobe.com
  [9]: http://www.google.com/chromeframe
  [10]: http://src.chromium.org/svn/trunk/src/chrome_frame/chrome_tab.idl
  [11]: http://blog.chromium.org/2013/06/retiring-chrome-frame.html
  [12]: http://webkitdotnet.sourceforge.net/

All Chromium Embedded Solutions on Gang of Coders

Total of 1 Chromium Embedded Solutions

Options for embedding Chromium instead of IE WebBrowser control with WPF/C#