Как лучше использовать версию файла и версию сборки?

В .NET есть два доступных номера версии при создании проекта, версии файла и версии сборки. Как вы используете эти цифры? Сохранять их то же самое? Автоматически увеличивать один, но вручную менять другой?

А как насчет атрибута AssemblyInformationalVersion?

Я нашел эту статью Microsoft Knowledge Base (KB), которая предоставила некоторую помощь: Как использовать версию сборки и версию файла сборки.

Ответы

Ответ 1

В сценарии, где у меня есть несколько сборок файлов (например, 1 exe и 5 dll), я буду использовать для каждой версии другую версию файла, но одну и ту же версию сборки для всех из них, позволяющую вам узнать, какая из этих библиотек идти с.

Ответ 2

В решениях с несколькими проектами одна вещь, которую я нашел очень полезной, состоит в том, чтобы все файлы AssemblyInfo указывали на один проект, который управляет версиями. Итак, у меня AssemblyInfos есть строка:

[assembly: AssemblyVersion(Foo.StaticVersion.Bar)]

У меня есть проект с единственным файлом, который объявляет строку:

namespace Foo
{
    public static class StaticVersion
    {
         public const string Bar= "3.0.216.0"; // 08/01/2008 17:28:35
    }
}

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

Я изменяю только строчный номер сборки, когда функциональный набор сильно меняется.

Я вообще не изменяю версию файла.

Ответ 3

В статье в KB упоминается самое важное различие: версии файлов используются только для целей отображения, тогда как версия сборки играет важную роль в поведении загрузки .NET.

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

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

Ответ 4

Версии файлов используются только для целей отображения, тогда как версия сборки играет важную роль в поведении загрузки .NET.

Не совсем. Версия файла также важна для установщика Windows при обновлении существующей версии по сравнению с предыдущей версией.

Ответ 5

В моем текущем приложении каждый проект VS имеет ссылку на исходный файл AssemblyBuildInfo, который имеет следующие атрибуты:

[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyCompany("Acme Corporationy")]
[assembly: AssemblyCopyright("Copyright ©  2009 Acme Corporation")]

Таким образом, все сборки в моем решении используют одну и ту же версию и информацию о компании (что означает, что если я должен ее изменить, я меняю ее только один раз). Исключая FileVersion, он автоматически устанавливается в AssemblyVersion.

Ответ 6

@Adam: Вы меняете версию файла с каждой сборкой? Используете ли вы контроль версий (SYN или VSS) и используете эту информацию, чтобы связать источник с двоичными файлами?

Кажется, имеет смысл, что версия Assembly остается прежней. то есть "2.0.0.0". Это соответствует развертыванию продукта.

Версия файла изменяется в соответствии с версией исходного элемента управления. "2.0.The.revision" Это обеспечило бы ссылку из определенной dll (или exe) на источник, который ее построил.

Ответ 8

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