將單獨的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合併爲一個用於開放源碼分發的程序集

回答

相關問題