将单独的DLL合并为一个用于开放源码分发的程序集

我已经编写了一个将要发布开源代码的lib。它使用MS Unity。我应该使用ILMerge将Unity DLL（Microsoft.Practices.Unity.dll & Microsoft.Practices.ServiceLocation.dll）合并到操作系统库中，我应该简单地将DLL放在OS DLL旁边还是两者都不？将单独的DLL合并为一个用于开放源码分发的程序集

来源

2012-02-14 Myles McDonnell

为什么不在自述文件中提到Unity是必备条件？此外，我不确定Unity许可证是否允许合并到第三方dll中并以这种方式分发。 – abatishchev 2012-02-14 11:10:26

我认为这是最好的方法。唯一令我感到担忧的是，除非消费者能够获得兼容的一致性，否则图书馆将变得毫无用处。我想这是一个常见问题。我已经使用了统一版的发行版，图书馆通过确切的版本来引用它，因此消费者只需要知道他们在做什么。 – 2012-02-14 11:15:19

我同意这就是问题所在。如果是企业环境，那么在某些个人消费者的情况下就不那么重要了。 – abatishchev 2012-02-14 11:22:36

我不会合并lib和MS Unity。由于MS Unity的Ms-PL许可证下，我会发布MS Unity程序集的良好版本以及lib。不要忘记在the license of MS Unity中包含readme.txt文件。

来源

2012-02-14 11:30:53 ken2k

非常好，谢谢。 – 2012-02-14 11:57:27

我建议编写一个说明如何使用NuGet包管理器获取Unity的完全版本。它应该减少最终用户的头痛。

还提供指向兼容的Unity版本列表的链接到Unity下载页面。

来源

2012-02-14 11:24:04 abatishchev

我不会建议你将任何第三方库合并成一个。原因很简单：通过这样做，您可以限制用户使用这些第三方库的另一个（或可能是定制的）版本。

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

如果你的图书馆应该被许多人使用，那么你可以预测有人更喜欢使用另一个容器，也许，当他们想要开始使用你的图书馆时，这些其他的容器已经在他们的应用程序中使用。很难想象你的用户会乐意放弃他们使用的内容并开始使用Unity，或者支持两个容器。我建议你将这些依赖关系抽象出来，并给你的潜在用户一个选择。

例如，在您的库中，您可以使用库中需要的所有方法（解析，注册等）来定义接口IContainer。您还可以实现另一个独立的DLL：SuperLibrary.Container.Unity.dll其中将包含一个通过Unity工作的实现IContainer。现在，如果我想在我的项目中使用Autofac以及您的lib，我将能够创建自己的SuperLibrary.Container.Autofac.dll，它可能包含一个或两个IContainer实现文件，并且很高兴你的lib的用户，因为我使用我的Autofac并且不需要知道关于任何Unity的任何东西:)

甚至你，如果你决定足够好，你可以为Autofac，Unity，Unity2， StructureMap，Spring.NET等，通过让用户选择使用哪个库来使用户满意。

来源

2012-02-14 12:01:12

将单独的DLL合并为一个用于开放源码分发的程序集

回答

相关问题