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

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

Answer 8

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