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

Question

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

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

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

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

Answer 1

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

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

Answer 2

Вот то, чем я жил -

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

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

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

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

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

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

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

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

Answer 3

Предоставление разных имен различным версиям сборки - самый простой способ и, безусловно, работает.

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

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