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

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

также насчет ?

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

55
.net attributes versions

8 ответов

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

14

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

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

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

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

74

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

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

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

22

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

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

12

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

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

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

11

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

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

версия файла изменяется в соответствии с редакцией из системы управления версиями. "2.0.??.редакция " это предоставит ссылку из определенной dll (или exe) на источник, который построил его.

3

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

2

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

0