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

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

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

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

Ответов (8)

Решение

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

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

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

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

Я написал сообщение в блоге на эту тему, которое может быть полезно сообществу http://blog.raffaeu.com/archive/2011/12/11/sharing-assembly-version-in-visual-studio-2010.aspx

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

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

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

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

В решениях с несколькими проектами я нашел очень полезным то, что все файлы 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
    }
}

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

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

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

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

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

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

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

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