C# 合并单独的DLL'；为开放源代码发行版将其集成到单个程序集中

我已经编写了一个lib，即将发布开源。它使用MS Unity。我应该使用ILMerge将Unity DLL（Microsoft.Practices.Unity.DLL和Microsoft.Practices.ServiceLocation.DLL）合并到操作系统库中吗？我应该简单地将DLL与操作系统DLL一起发送还是两者都不发送？

我建议编写一条指令，说明如何使用NuGet软件包管理器获取Unity的准确版本。这将减少终端用户的头痛

---

还提供指向Unity下载页面的链接，并指定兼容的Unity版本列表

我不会合并lib和MS Unity

---

由于MS Unity是在MS PL许可证下的，因此我将随lib一起发布MS Unity程序集的良好版本。别忘了在中包含一个

readme.txt

文件。

我不建议您将任何第三方库合并到您的库中。 原因很简单：通过这样做，您可以限制您的用户使用这些第三方库的其他（或可能是自定义）版本

我建议将这些DLL与库一起提供，只要包含对解决方案的NuGet包引用（如果是开源库的话）。 这对于任何第三方库都是建议的，但是对于诸如IoC容器、记录器和其他常用问题，您通常希望为用户提供更多的灵活性

如果你的库被很多人使用，那么你可以预测有人更愿意使用另一个容器， 也许，当这些其他容器想要开始使用您的库时，它们已经在应用程序中使用了。很难想象您的用户会乐意放弃他们使用的东西，转而使用Unity，或者支持两个容器。 我建议您将这些依赖项抽象出来，并给您的潜在用户一个选择

例如，在您的库中，您可以定义一个接口IContainer，其中包含您的库从容器中需要的所有方法（解析、注册等）。您还可以实现另一个单独的DLL:SuperLibrary.Container.Unity.DLL，它将包含一个通过Unity工作的实现IContainer。 现在，如果我想在我的项目中与您的库一起使用Autofac，我将能够创建我自己的SuperLibrary.Container.Autofac.dll，它可能包含一个或两个用于IContainer实现的文件，并且是您的库的愉快用户，因为我使用我的Autofac，不需要了解任何统一：）

---

即使是你，如果你决定表现得足够好，你也可以为Autofac、Unity、Unity2、StructureMap、Spring.NET等提供单独的DLL，让用户选择使用哪一个库来满足他们的需求。

为什么不在自述文件中提一下Unity是先决条件？此外，我不确定Unity许可证是否允许合并到第三方DLL中并以这种方式分发。我认为这是最好的方法。唯一让我担心的是，除非消费者能够获得统一的兼容版本，否则该库将变得毫无用处。我想这是一个普遍的问题。我使用的是unity的发布版本，而库中引用的是确切的版本，因此消费者只需知道他们在做什么。我同意这就是问题所在。在企业环境中，这比在某些个人消费者等情况下更有意义。在我看来，依赖IoC容器的库有点奇怪。通常只有应用程序依赖于容器。@CodeInChoas我明白你的意思，也许我的理解是错误的。也许我应该重构以消除Unity，并在如何解决依赖关系方面给予消费者更多的灵活性。