c# - 作为嵌入式资源的托管 dll

Question

将所有必需的托管 dll 作为嵌入式资源捆绑到 .NET 库项目以便只发送一个 dll 是否是一种好习惯？

背景：我已经创建了一个 API 作为 .NET dll（在 C# 中），并且一切正常。但是该库对其他托管库（大约 15 个 dll）有相当多的依赖，所以我也需要分发这些库。

当我的 API 的用户创建了一个应用程序时，他们必须再次确保将所有这些 dll 与应用程序一起分发。对我来说，如果他们只考虑一个 dll 似乎会更好。

我可以看到使用嵌入式 dll 的主要缺点是它们必须在动态加载之前解压缩到临时文件夹，这可能会或可能不会有性能和稳健性问题。

Answer 1

围绕这一点有很多问题。如果您期望加载特定于平台的依赖项（即 x86 与 x64），或者使用您的 API 的应用程序确实如此，会发生什么？这是否意味着您还需要在包中包含特定的 x86 与 x64 程序集？它很快变得多毛。

对于这些类型的方案，您应该考虑使用ClickOnce 部署。然后，所有依赖项将打包在一起。

实际上，这是 API 消费者要解决的问题，而不是 API 生产者要解决的问题。如果你的 API 有很多外部依赖项，它可能不太受欢迎，但你必须在那里做出决定，什么对你的 API 成功至关重要。