Any reason to prefer CefSharp over CefGlue (or vice-versa)?
在为.Net提供不错的Chromium嵌入式框架(CEF)的实现领域中,两个领先的选择似乎是CefSharp和CefGlue。 它们的方法不同(CefGlue使用P / Invoke来调用CEF非托管代码,CefSharp使用围绕CEF库的混合模式C ++ / CLI包装器)。
出于某种原因,混合模式程序集比P / Invoke调用好吗? 在所有其他条件相同的情况下,似乎CefGlue(P / Invoke库)为CEF项目提供了"更薄"的包装,这意味着响应上游库中的更新可能更快。
是否有任何人有两个库的经验,可以分享差异化的因素?
从某种意义上说,它们大致相同,无论您选择哪种结构,都应该能够在2014年摆脱困境。我们前段时间遇到了这个问题,以下是我们的建议:
CefSharp
优点:
缺点:
头孢胶
优点:
缺点:
现在是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。
现在到了2018年底,老实说看起来很严峻。
CefSharp虽然处于积极开发中并且提供了一些不错的文档,但仍然不支持.Net Core或Mono,使其无法用于任何与.Net Core,.Net Standard或Mono相关的内容(我们在生产服务器上独家使用Linux,因此这很难可悲的是)。
相比之下,根据其他海报,CefGlue显然支持.Net Core / Mono。但是,这一点很重要,该项目已移至Gitlab,并且未附加任何许可证。该网站也无法访问(至少是我找到的那个网站)并且文档不存在。
虽然这里有一个叉子,但它似乎再次处于非活动状态。 .Net Core也有一个非官方的端口,但是这似乎对Avalonia有很强的依赖性。
但是,有Chromely,它似乎支持跨平台,并且基于CefSharp和CefGlue(以及这些端口的非官方端口)。看来这是一个完全成熟的浏览器,而不是一个用于在应用程序中嵌入内容的库。
由于我最初是在寻找一种将无头浏览器嵌入应用程序中以进行爬网的简便方法(从而消除了安装Chrome的必要性),所以我也研究了Awesomium,但它们似乎已移至名为" Ultralight"的新项目中。 ,它不支持C#,并且目前没有绑定。
作为最后的努力,似乎有Optimus,它似乎支持.Net Standard,并且是在.Net中减去GUI的WebBrowser的完整实现。我会尝试一下,如果可行(或无效),请编辑此答案。
为了完成Artem的回答,CefSharp仅提供了与C#的基本javascript集成,而CefGlue通过公开CEF提供的所有javascript绑定提供了一个非常完整的集成解决方案。
关于Nugets包,我刚刚为.Net 4.5创建了CEFGlue nuget包,目标是3.2272.2035 CEF版本:Unofficial.CefGlue.WPF和Unofficial.CefGlue.WindowsForm。