Лучшие практики для слияния сборок?

Question

Мне интересно, какова эвристика при создании выпусков библиотек для включения в другие проекты в отношении зависимостей и нужно ли мне их включать или нет.

Моя проблема заключается в следующем:

У меня есть библиотека CommonUtilities, которая в качестве названия подразумевает набор утилит, которые можно использовать более чем в одном месте. Зависимости CommonUtilities включают log4net.dll (каркас ведения журнала) и Oracle.DataAccess.dll (драйвер базы данных).

У меня есть другой проект под названием MyProject, в который я хочу включить CommonUtilities. MyProject также зависит от Oracle.DataAccess.

Если я использую ILMerge и объединяю CommonUtilities в одну сборку CommonUtilities.dll и указываю, что из MyProject все компилируется, но я уверен, что должен явно ссылаться на Oracle.DataAccess из MyProject, поскольку это зависимость, а не использовать сборку, объединенную в CU , Добавление ссылки на Oracle.DataAccess также приводит к неоднозначным операторам использования, так как на них ссылаются две сборки Oracle.DataAccess.

Использование ILMerge / Internalize в моем случае приводит к ошибкам компиляции, поскольку типы из встроенной сборки Oracle.DataAccess возвращаются из CommonUtilities и, поскольку они помечены как внутренние, MyProject не распознает возвращенный тип.

Единственный способ заставить эту работу просто не объединять эту конкретную сборку (Oracle.DataAccess) с CommonUtilities и ссылаться только на нее из MyProject. Это, в свою очередь, создает новую проблему: на какой Oracle.DataAccess.dll я должен ссылаться - на зависимость, распространяемую с помощью CommonUtils или нет?

Есть ли другие способы сделать все это?

Answer 1

Короткая, простая версия:

Каждая ссылка в рамках одного процесса на данную сборку должна ссылаться на одну и ту же версию.

Если вы этого не сделаете, вы можете столкнуться с серьезными проблемами, потому что одна часть приложения не может общаться с другой из-за несовпадения версий.

Даже с такими «по-настоящему приватными» вещами, как log4net, вы можете упустить возможности для общего пространства конфигурации, например, использовать общий корневой логгер для всех частей приложения. Конечно, последний звонок в этом случае - как всегда - с ответственным разработчиком.

См. Также этот другой вопрос о ILMerge и сторонних сборках .

Answer 2

Самая большая причина, по которой мы используем ILMerge, состоит в том, чтобы сделать наш шаг запутывания намного более трудным для изменения. Объединяя их вместе с помощью флага / internalize, обфускатор может затем переименовать открытые классы и методы, которые мы объединили в родительскую сборку.

Из документации по слиянию IL: «[Internalize] управляет изменением видимости типов в сборках, отличных от основной сборки. Если это так, то видимость всех неисключаемых типов, видимых за пределами их сборки, изменяется таким образом, что они не видны снаружи. объединенная сборка "

Если сборки хранятся отдельно, то обфускатор не будет их переименовывать.

Кстати, Eazfuscator - это круто и бесплатно: http://www.foss.kharkov.ua/g1/projects/eazfuscator/dotnet/Default.aspx

Answer 3

Мы не объединяем библиотеки вообще. Я не вижу большого преимущества в объединении библиотек, которое вы не можете получить, а просто собрать их в одну сборку.

Я вижу преимущества слияния библиотек с EXE. Это может быть очень удобно. Проблема слияния библиотек в том, что они могут иметь разные версии зависимости в вашем EXE-файле, что может создавать неудобства для приятелей.

Я не думаю, что объединение библиотек вместе может считаться лучшей практикой, за исключением случаев, когда вы объединяете их в EXE-файл для представления одного файла вместо нескольких файлов.

Answer 4

Я полагаю, что может быть какое-то преимущество в том, чтобы хранить несколько локализованных сборок в одной (что, я даже не уверен, что вы можете сделать)

Я бы не стал объединять библиотеки других поставщиков - потому что они часто имеют свое собственное лицензирование, и для их обновления вам потребуется распространять новую версию вашего кода.

Объединение ваших собственных библиотек может быть выгодно, если у вас есть много библиотек для поддержания каталога в чистоте, или убедитесь, что какой-то код ВСЕГДА будет с основной исполняющей сборкой.

Я думаю, что ILMerge лучше справляется с объединением библиотек в EXE, поэтому у вас есть один файл вместо многих.