有没有理由比CefGlue更喜欢CefSharp（反之亦然）？

Question

在为.Net提供体面的Chromium Embedded Framework（CEF）实现方面，两个主要选项似乎是CefSharp和CefGlue。它们的方法不同（CefGlue使用P / Invoke调用CEF非托管代码，CefSharp使用围绕CEF库的混合模式C ++ / CLI包装器。）

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

是否有人在这两个图书馆都有经验可以分享差异化因素是什么？

Answer 1

从某种意义上讲，它们大致相同，无论你选择哪一个，你都应该在2014年能够逃脱。我们前一段时间有这个问题，而且我们已经提出了这个问题：

CefSharp

加号：

1. WinForms是一个非常古老而成熟的项目。如果您要使用WinForms，那么可能就是这样;
2. 它有一个NuGet包，因此易于使用和更新;
3. 支持较新版本的WPF（.NET 4 +）;

劣势：

1. 正如@Uwe Keim所提到的，他们最近刚刚开始支持WPF，所以它不像Xillium.CefGlue那样成熟;
2. 社区不接受您的需求;
3. 没有Mono支持。

CefGlue

加号：

1. 它是.NET 2.0友好的。您的代码将能够在其上运行。 （这对我们来说至关重要）
2. 一个非常敏感的社区，可以帮助您获得您需要完成/修复的内容;
3. 对WPF的更成熟的支持;
4. 单声道支持。

劣势：

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

Answer 2

现在是2018年。项目命运发生了很大变化。 CefSharp仍然存在并且几乎每天都在github存储库中进行更新。问题已得到解决，目前只有57个未解决的问题，1787年已结束。 CefGlue似乎做得不好。邮件列表已死，没有最新更新。 github上有两个分支可以解决最新发布的CefGlue版本以外的问题。

否则，基本面没有改变。 CefSharp依赖于C ++ / CLI代码，这通常是使.NET-to-C ++互操作进行的一种简单方法。但这仅适用于Windows计算机和面向.NET Framework完整桌面版本的项目。

但不是Mono，不是.NETCore（与Xamarin和UWP应用程序有关），也不是要移植到其他OS的任何库或项目。在这种情况下，不能选择C ++ / CLI，并且必须将pinvoke作为后备。所以CefGlue。

Answer 3

现在已经到2018年末了，老实说看起来很冷酷。

CefSharp虽然正在积极开发中并且提供了一些不错的文档，但仍然不支持.Net Core或Mono，使其无法用于任何与.Net Core，.Net Standard或Mono相关的内容（我们在生产服务器中完全使用Linux）一辛苦没有悲伤）。

相比之下，根据其他海报，CefGlue显然支持.Net Core / Mono。 但是，这一点很重要，该项目已移至Gitlab，并且未附加任何许可证。该网站也无法访问（至少是我找到的那个网站）并且文档不存在。

有一个分叉here，尽管它似乎再次处于非活动状态。 .Net Core here也有一个非官方的端口，但这似乎对Avalonia有着很强的依赖性。

但是，有Chromely，它似乎支持跨平台，并且基于CefSharp和CefGlue（以及这些端口的非官方端口）。似乎这是一个完全成熟的浏览器，而不是一个用于在应用程序中嵌入内容的库。

由于我最初一直在寻找一种简单的方法来将无头浏览器嵌入应用程序中以进行爬网（从而无需安装Chrome），因此我也研究了Awesomium，但它们似乎已经转移到了一个名为“ “ Ultralight”，它不支持C＃，目前没有绑定。

作为最后的努力，似乎有Optimus，它似乎支持.Net Standard，并且是.Net（减去GUI）中WebBrowser的完整实现。我会尝试一下，如果可行（或无效），请编辑此答案。

Answer 4

要完成Artem的回答， CefSharp 仅提供与C＃的基本javascript集成，而 CefGlue 通过公开CEF提供的所有javascript绑定提供更完整的集成解决方案。

关于Nugets包，我刚为.Net 4.5创建了 CEFGlue nuget包，目标是3.2272.2035 CEF版本：Unofficial.CefGlue.WPF和Unofficial.CefGlue.WindowsForm。