有没有理由比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应用程序相关)或任何旨在可移植到其他操作系统的库或项目.在这种情况下,C++/CLI不是一个选项,并且pinvoke必须是后备.所以CefGlue.

Answer 3

现在到了2018年末，诚实地看起来很严峻。

CefSharp虽然处于积极开发中并且提供了一些不错的文档，但仍然不支持.Net Core或Mono，使其无法用于任何与.Net Core，.Net Standard或Mono相关的内容（我们将Linux专用于生产服务器，因此这很难可悲的是）。

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

虽然这里有一个叉子，但它似乎再次处于非活动状态。此外，还有一个非官方的端口到.NET的核心位置，但似乎对阿瓦隆尼亚hard依赖。

但是，有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。