.net: номера версий для DLL и EXE?

Вы, вероятно, получите несколько мнений, но я бы посоветовал не усложнять и синхронизировать версии EXE и DLL. Я могу изменить свое мнение, если вы действительно намерены выпускать версии DLL и EXE независимо друг от друга, но вы не упоминаете об этом как о требовании. Этот подход следует использовать, если вы рассматриваете некоторые из ваших файлов как сторонние компоненты (которые выпускаются по графику, отличному от основного продукта). Но опять же, если у вас нет этого требования, я бы посоветовал просто синхронизировать все версии файлов.

Соглашение, которое я видел, хорошо работает, состоит в том, чтобы использовать первые 3 числа для представления версии продукта (основная/дополнительная и т. д.), а 4-я часть номера версии представляет версию системы управления версиями (так что вы точно знаете, какие исходные файлы содержат двоичный файл). пришли из).

Надеюсь, это поможет,

Джон

На мой взгляд, вы должны управлять их версиями отдельно.

Потому что 2 приложения (EXE) могут использовать одну и ту же DLL. Какая версия DLL будет?

Версия DLL не должна зависеть от исполняемого файла EXE.

На мой взгляд, у вас должен быть только один файл AssemblyInfo, общий для всего приложения. Таким образом, его легко поддерживать. И, конечно же, это подразумевает, что у вас есть одна версия для всех ваших сборок, что для меня является приемлемой нормой. см. это< /а>.

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

Таким образом, если у вас есть приложение, развернутое как основной исполняемый файл и несколько dll, и эти dll НЕ ЯВЛЯЮТСЯ частью какого-либо другого приложения, вы можете чувствовать себя в безопасности, даже если полностью забудете о версионировании dll.

В противном случае, если dll будут частью нескольких проектов, увеличивайте их версию до ЛЮБОЙ схемы, которая кажется вам логичной, например, увеличивайте МИНОР 1.X.0.0, когда вы добавляете какой-то функционал или изменяете что-то довольно большое, увеличивайте ОСНОВНУЮ, если у вас есть внутри совершенно разные классы,...

Что касается увеличения MAJOR за счет функциональности, то это конечно опять же личный вкус, я бы посоветовал там что-то вроде:

• увеличьте MINOR, если функциональность добавлена, и достигнута какая-то важная веха
• увеличьте MAJOR, если вы измените парадигму пользовательского интерфейса, что предполагает, что вы сделали существенный редизайн или переписали.

Также: Объяснение синтаксиса версии?

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

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

Две основные цели управления версиями — параллельное выполнение и отслеживание. Параллельное выполнение (SxS) позволяет выполнять несколько версий одной и той же библиотеки DLL в одном приложении. Без изменения номера версии сборки это невозможно. Отслеживание — это просто возможность определить точный моментальный снимок кода, который выполняется на компьютере клиента. Оба могут быть достигнуты путем изменения версии сборки, но первое может быть достигнуто только путем изменения версии сборки.

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

Например, если вы используете какую-либо форму абстракции контракта (определение зависимостей между библиотеками DLL через интерфейсы, а не конкретные типы), вы можете разделить свое приложение на несколько «хранилищ версий». Примером этого может быть клиент и сервер, где взаимозависимость, если она определена в 3-й сборке, заключает контракты WCF. Если они все версии отдельно, то вы можете выпустить новую версию сервера (при условии, что она соответствует тому же контракту), не затрагивая клиента. И наоборот.

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

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

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

Простой ответ — увеличивать номера версий по мере внесения изменений. Не синхронизируйте EXE и DLL, потому что для этого нет причин. DLL предназначена для переноса — теоретически ее может использовать любой EXE-файл. Если у вас уже есть номер версии для DLL, используйте его в качестве текущего базового уровня, а по мере его изменения увеличивайте номер версии по мере необходимости.