是否有理由更喜欢CefSharp而不是CefGlue (反之亦然)？

Question

在为.Net提供一个像样的Chromium嵌入式框架实现的领域中，两个领先的选择似乎是CefSharp和CefGlue。它们在方法上有所不同(CefGlue使用P/Invoke调用CEF非托管代码，CefSharp使用混合模式的C++/CLI包装器封装CEF库)。

混合模式的程序集比P/Invoke调用更好是有什么原因的吗？在其他条件相同的情况下，CefGlue ( P/Invoke lib)似乎为CEF项目提供了一个“更薄”的包装器，这意味着它可能会更快地响应上游库中的更新。

有没有对这两个库都有经验的人可以分享区分因素是什么？

Answer 1

从某种意义上说，它们几乎是一样的，无论你选择哪一个，你都应该能够在2014年逃脱惩罚。我们在一段时间前遇到了这个问题，下面是我们得到的结论：

CefSharp

优点：

• WinForms是一个非常古老和成熟的项目。如果你要使用WinForms，它可能是个不错的选择；

1. 它有一个NuGet包，所以它很容易使用和更新版本的WPF (.NET 4+);

缺点：

正如@Uwe Keim提到的那样，

1. 最近终于开始支持WPF了，所以它并不成熟，因为Xillium.CefGlue;
2. Community不能接受你的需求；
3. 没有Mono支持。

CefGlue

优点：

1. It是.NET 2.0友好的。您的代码将能够在其上运行。(这对我们很重要)
2. 是一个响应性很强的社区，它可以帮助您获得所需的done/fixed;
3. More成熟的WPF支持；
4. Mono支持。

缺点：

1. 没有NuGet包据我所知，您需要自己添加库并更新它们

Answer 2

现在是2018年。项目的命运已经发生了很大的变化。在GitHub存储库中，CefSharp几乎每天都会更新，而且运行良好。问题正在得到解决，目前只有57个开放问题和1787个关闭问题。CefGlue似乎做得并不好。邮件列表是垂死的，没有最近的更新。GitHub有两个分支，它们解决了上一个发布的CefGlue版本之外的问题。

除此之外，基本面并没有改变。CefSharp依赖于C++/CLI代码，最初是一种实现.NET到C++互操作的简单方法。但这只能在Windows机上和针对.NET框架的完整桌面版本的项目中工作。

但不是Mono，不是.NET核心(与Xamarin和UWP应用程序相关)，也不是任何旨在移植到另一个操作系统的库或项目。在这种情况下，C++/CLI不是一个选项，而pinvoke必须是后备选项。所以CefGlue。

Answer 3

现在是2018年末，老实说，情况看起来很严峻。

虽然CefSharp正在积极开发中，并且有一些不错的文档，但仍然不支持Linux或Mono，这使得它无法用于任何与.NET核心、.NET标准或Mono相关的东西(我们只将.NET用于生产服务器，所以这是一个很难回答的问题，可悲的是)。

相比之下，根据其他海报，CefGlue显然支持.NET核心/单声道。然而，这一点很重要，该项目转移到了GitLab，并且没有任何附加的许可证。这个网站也无法访问(至少我找到的那个)，文档也不存在。

不过，还有一个似乎又处于非活动状态的fork here。还有一个到.NET核心here的非官方端口，但它似乎对Avalonia有很强的依赖性。

但是，也有Chromely，它似乎支持跨平台，并且基于CefSharp和CefGlue (以及它们的非官方端口)。这看起来像是一个完全成熟的浏览器，而不是一个用来在你的应用程序中嵌入某些东西的库。

由于我最初在寻找一种简单的方法来在我的应用程序中嵌入无头浏览器用于爬行目的(消除安装Chrome的需要)，我也研究了Awesomium，但他们似乎已经转移到一个名为"Ultralight“的新项目中，该项目目前不支持C#，也没有绑定。

作为最后的努力，似乎有Optimus，它似乎支持.NET标准，并且是WebBrowser在.NET中的完整实现，但不包括图形用户界面。我会试一试，如果它能用(或不能)，我可能会编辑这个答案。