Internet Explorer-based WPF WebBrowser control suffers from some keyboard and focus issues and memory leak issues. As an alternative solution to these problems, we'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 here previously. I'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:
It looks very appropriate, but I don'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) and .NET bindings for CEF
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.
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 for interaction with the inner web page (onmessage, addEventListener/removeEventListener, postMessage).
I'm aware Google is to discontinue 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.
Not exactly Chromium-based and doesn'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? Thank you.
[EDITED] I'd also like to thank artlung for giving this question a boost by providing a generous bounty offer.
You've already listed the most notable solutions for embedding Chromium (CEF, Chrome Frame, Awesomium). There aren't any more projects that matter.
There is still the Berkelium project (see Berkelium Sharp and Berkelium Managed), but it emebeds an old version of Chromium.
CEF is your best bet - it's fully open source and frequently updated. It's the only option that allows you to embed the latest version of Chromium. Now that Per Lundberg is actively working on porting CEF 3 to CefSharp, this is the best option for the future. There is also Xilium.CefGlue, but this one provides a low level API for CEF, it binds to the C API of CEF. CefSharp on the other hand binds to the C++ API of CEF.
Adobe is not the only major player using CEF, see other notable applications using CEF on the CEF wikipedia page.
Updating Chrome Frame is pointless since the project has been retired.
We had exactly the same challenge some time ago. We wanted to go with CEF3 open source library which is WPF-based and supports .NET 3.5.
Firstly, the author of CEF himself listed binding for different languages here.
Secondly, we went ahead with open source .NET CEF3 binding which is called Xilium.CefGlue and had a good success with it. In cases where something is not working as you'd expect, author usually very responsive to the issues opened in build-in bitbucket tracker
So far it has served us well. Author updates his library to support latest CEF3 releases and bug fixes on regular bases.
Here is another one:
http://www.essentialobjects.com/Products/WebBrowser/Default.aspx
This one is also based on the latest Chrome engine but it's much easier to use than CEF. It's a single .NET dll that you can simply reference and use.
Take a look at the DotNetBrowser library developed by the team I belong to. It provides Chromium-based WPF and WinForms browser controls, which are quite easy to embed into .NET application. It supports all the modern web standards including HTML5, CSS3 and JavaScript. The rendered page looks exactly like in Google Chrome.
The library inherits Chromium's multi-process architecture – each web page is rendered in a separate Chromium process, and the application will continue working even after plugin crash or any other unexpected error occurs on the web page.
Here are some other useful features, provided by DotNetBrowser: it is possible to listen to load events, handle network activity, configure proxy, simulate user actions, work with cookies, access and modify DOM, listen to DOM events, call JavaScript from .NET and vice versa, use web camera and microphone on the web page, set up WebRTC-based communication, and more.
Check out the API Reference for more details.
The code snippet below demonstrates how to create a BrowserView, embed it into a Form, and load a URL:
using System.Windows.Forms;
using DotNetBrowser;
using DotNetBrowser.WinForms;
namespace WinForms.DotNetBrowser
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
BrowserView browserView = new WinFormsBrowserView();
Controls.Add((Control) browserView);
browserView.Browser.LoadURL("http://www.youtube.com");
}
}
}
Once you run the example above you will get the following output:
The library is commercial. Commercial licenses include support packages for different team sizes. It is also possible to purchase the library’s source code.
Besides its own page the component is available as NuGet package and as VSIX package in the Visual Studio Marketplace.
I have used Awesomium.NET. Although I don't like the fact that it's not open-source, and also the fact that it uses a pretty old Webkit rendering engine, it is really easy to use. That's about the only endorsement I can give it.
UPDATE 2018 MAY:
Alternatively, you can embed Edge browser, but only targetting windows 10.
I had same issue with my WPF RSS reader, I originally went with Awesomium (I think version 1.6) Awesomium is great. You get a lot of control for caching (images and HTML content), JavaScript execution, intercepting downloads and so forth. It's also super fast. The process isolation means when browser crashes it does not crash the app.
But it's also heavy, even release build adds about 10-15mb (can't remember exact number) and hence a slight start-up penalty. I then realized, only problem I had with IE browser control was that it would throw the JavaScript errors every now and again. But that was fixed with the following snippet.
I hardly used my app on XP or Vista but on Win 7 and above it never crashed (at least not because I used IE browser control)
IOleServiceProvider sp = browser.Document as IOleServiceProvider;
if (sp != null)
{
IID_IWebBrowserApp = new Guid("0002DF05-0000-0000-C000-000000000046");
Guid IID_IWebBrowser2 = new Guid("D30C1661-CDAF-11d0-8A3E-00C04FC9E26E");
webBrowser;
sp.QueryService(ref IID_IWebBrowserApp, ref IID_IWebBrowser2, out webBrowser);
if (webBrowser != null)
{
webBrowser.GetType().InvokeMember("Silent",
BindingFlags.Instance | BindingFlags.Public | BindingFlags.PutDispProperty, null, webBrowser, new object[] { silent });
}
}
来源：https://stackoverflow.com/questions/18119125/options-for-embedding-chromium-instead-of-ie-webbrowser-control-with-wpf-c