托管dll作为嵌入式资源

Question

将所有必需的托管dll作为嵌入资源捆绑到.NET库项目以便只发送一个dll是不错的做法？

背景： 我已经创建了一个API作为.NET DLL（在C＃中），它的工作正常。但是该库对其他托管库（大约15个dll）有很多依赖性，所以我也需要分发它们。

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

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

Answer 1

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

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

实际上，API消费者要解决这个问题，而不是API生产者。如果您的API有很多外部依赖关系，那么它可能不那么受欢迎，但您必须在那里做出关于API成功的关键因素的决定。