Я написал lib, который я собираюсь опубликовать с открытым исходным кодом. Он использует MS Unity. Должен ли я объединить DLL Unity (Microsoft.Practices.Unity.dll & Microsoft.Practices.ServiceLocation.dll) в библиотеку ОС с использованием ILMerge, должен ли я просто отправлять DLL вместе с библиотекой ОС или нет?Объединить отдельные библиотеки DLL в единую сборку для распространения с открытым исходным кодом
Я бы не слил lib и MS Unity.
Поскольку MS Unity находится под лицензией Ms-PL, я отправил бы хорошую версию сборок MS Unity вместе с lib. Не забудьте указать файл readme.txt с the license of MS Unity.
Отлично, спасибо. –
Предлагаю написать инструкцию, как получить точно версию Unity с помощью диспетчера пакетов NuGet. Это должно уменьшить головную боль конечных пользователей.
Также у поставщика есть ссылка на страницу загрузки Unity с указанием совместимого списка версий Unity.
Я бы не предложил вам объединить любые сторонние библиотеки в свой. Причина проста: при этом вы запрещаете пользователям использовать другие (или, возможно, пользовательские) версии этих сторонних библиотек.
Я бы порекомендовал доставку этих библиотек вместе с вашими библиотеками так долго, как включить ссылку на пакет NuGet на решение (если это библиотека с открытым исходным кодом). Рекомендуется для любых сторонних библиотек, но для таких вещей, как контейнеры IoC, регистраторы и другие часто используемые проблемы, вы, как правило, хотите предоставить пользователям дополнительную гибкость.
Если ваша библиотека должна использоваться многими, вы можете предсказать, что кто-то предпочтет использовать другой контейнер, Возможно, эти другие контейнеры уже используются в своих приложениях, когда они хотят начать использовать вашу библиотеку. Трудно представить, что ваши пользователи будут рады отказаться от того, что они используют, и начать использовать Unity или поддерживать два контейнера. Я бы рекомендовал вам отвлечь эти зависимости и дать вашим потенциальным пользователям выбор.
Например, в вашей библиотеке вы можете определить интерфейс IContainer со всеми методами, которые необходимы вашей библиотеке из контейнера (Resolve, Register и т. Д.). Вы также можете реализовать другую отдельную DLL: SuperLibrary.Container.Unity.dll, которая будет содержать IContainer реализации, который работает через Unity. Теперь, если я хочу использовать Autofac в моем проекте вместе с вашей библиотекой, я бы смог создать свою собственную SuperLibrary.Container.Autofac.dll, которая, возможно, будет содержать один или два файла для вашей реализации IContainer и быть счастливой пользователь вашей библиотеки, потому что я использую мой Autofac и не должен знать ничего о любом Unity :)
Или даже если вы решите быть достаточно хорошим, вы можете отправить отдельные DLL для Autofac, Unity, Unity2, StructureMap, Spring.NET и т. Д., Чтобы сделать ваших пользователей счастливыми, предоставив им выбор того, какую библиотеку использовать.
Почему в файле readme не упоминается, что Unity является обязательным условием? Также я не уверен, что лицензия Unity позволяет объединиться в сторонние DLL и распространять ее таким образом. – abatishchev
Что я думаю, это лучший подход. Единственное, что касается меня, это то, что библиотека становится бесполезной, если потребители не могут получить совместимое доказательство единства. Полагаю, это распространенная проблема. Я использовал версию единства, и библиотека ссылается на нее точной версией, поэтому потребители просто должны знать, что они делают. –
Я согласен, что это проблема. В случае с корпоративной средой это имеет меньше смысла тогда в случае какого-то отдельного потребителя и т. Д. – abatishchev