有什么理由更喜欢 CefSharp 而不是 CefGlue（反之亦然）？

从某种意义上说，它们大致相同，无论你选择哪一个，你都应该能够在2014年逃脱。我们前段时间有这个问题，这里我们想到了：

Cef夏普

优点：

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

缺点：

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

Cef胶水

优点：

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

缺点：

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

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

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

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

除此之外，基本面没有改变。CefSharp 依赖于 C++/CLI 代码，最初是一种获取 .NET 到 C++ 互操作正在进行中。但这只能在 Windows 计算机和面向 .NET Framework 完整桌面版本的项目中工作。

但不是 Mono、.NET Core（与 Xamarin 和 UWP 应用相关）或任何旨在移植到另一个操作系统的库或项目。 在这种情况下，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 中 WebBrowser 的完整实现，减去 GUI。我会尝试一下，如果它有效（或无效），我可能会编辑这个答案。