Названия и версии сборок

Question

Что считается лучшей практикой, когда речь идет о сборках и выпусках?

Я хотел бы иметь возможность ссылаться на несколько версий одной и той же библиотеки — решение содержит несколько проектов, которые зависят от разных версий библиотеки commonutils.dll, которую мы создаем сами.

Поскольку все зависимости копируются в bin/debug или bin/release, там может существовать только одна копия commonutils.dll, несмотря на то, что каждый из файлов DLL имеет разные номера версий сборки.

Должен ли я включать номера версий в имя сборки, чтобы иметь возможность ссылаться на несколько версий библиотеки, или есть другой способ?

Answer 1

Вот чем я живу...

Это зависит от того, для чего вы планируете использовать файлы DLL.Я разделяю их на две основные группы:

1. Тупиковые сборки.Это файлы EXE и DLL, на которые вы действительно не планируете ссылаться откуда-либо.Просто назовите их и убедитесь, что номера версий, которые вы выпускаете, отмечены в системе управления версиями, чтобы вы могли в любой момент выполнить откат.

2. Ссылочные сборки.Дайте им строгие имена, чтобы другие сборки могли ссылаться на несколько их версий.Используйте полное имя для ссылки на них (Assembly.Load).Сохраните копию последней и лучшей версии в месте, где другой код может ссылаться на нее.

Далее у вас есть выбор: копировать локальные или нет ваши ссылки.По сути, компромисс сводится к следующему: хотите ли вы использовать патчи/обновления из ваших ссылок?В этом может быть положительная польза от получения новой функциональности, но, с другой стороны, могут быть и критические изменения.Решение здесь, я считаю, должно приниматься индивидуально в каждом конкретном случае.

При разработке в Visual Studio по умолчанию вы используете последнюю версию компилировать with, но после компиляции ссылочная сборка потребует конкретной версии, с которой она была скомпилирована.

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

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

Как только вы достигнете среды выполнения, вы сможете выполнить сборку. Загрузите все, что хотите, в домен приложения.Затем вы можете использовать Assembly.GetType, чтобы получить нужный тип.Если у вас есть тип, который присутствует в нескольких загруженных сборках (например, в нескольких версиях одного и того же проекта), вы можете получить Исключение неоднозначного матча исключение.Чтобы решить эту проблему, вам нужно будет получить тип из экземпляра переменной сборки, а не из статического метода Assembly.GetType.

Answer 2

Сборки могут сосуществовать в GAC (глобальном кэше сборок), даже если они имеют одно и то же имя, но версии разные.Вот как работают поставляемые сборки .NET Framework.Требование, которое должно быть выполнено для того, чтобы собрание могло быть зарегистрировано в GAC, должно быть подписано.

Добавление номеров версий к имени сборки просто противоречит всей цели экосистемы сборки и, по моему мнению, является громоздким.Чтобы узнать, какая версия данной сборки, я просто открываю окно «Свойства» и проверяю версию.

Answer 3

Давать разные имена разным версиям сборки — самый простой способ, и он наверняка работает.

Если ваша сборка (commonutils.dll) имеет строгое имя (т.подписано), вы можете подумать об установке его в GAC (глобальный кэш сборок - вы можете устанавливать разные версии одной и той же сборки параллельно в GAC), поэтому вызывающее приложение автоматически получает оттуда нужную версию, потому что .NET Типы включают информацию о версии сборки.

В вашем проекте VS вы ссылаетесь на правильную версию библиотеки, но не развертываете ее в папке приложения;вместо этого вы устанавливаете его в GAC (во время установки приложения).