В .NET есть два доступных номера версии при создании проекта, версии файла и версии сборки. Как вы используете эти цифры? Сохранять их то же самое? Автоматически увеличивать один, но вручную менять другой?
А как насчет атрибута AssemblyInformationalVersion?
Я нашел эту статью Microsoft Knowledge Base (KB), которая предоставила некоторую помощь: Как использовать версию сборки и версию файла сборки.
В сценарии, где у меня есть несколько сборок файлов (например, 1 exe и 5 dll), я буду использовать для каждой версии другую версию файла, но одну и ту же версию сборки для всех из них, позволяющую вам узнать, какая из этих библиотек идти с.
В решениях с несколькими проектами одна вещь, которую я нашел очень полезной, состоит в том, чтобы все файлы 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
}
}
Мой автоматизированный процесс сборки затем просто меняет эту строку, вытаскивая самую последнюю версию из базы данных и увеличивая второй номер.
Я изменяю только строчный номер сборки, когда функциональный набор сильно меняется.
Я вообще не изменяю версию файла.
В статье в KB упоминается самое важное различие: версии файлов используются только для целей отображения, тогда как версия сборки играет важную роль в поведении загрузки .NET.
Если вы измените номер версии сборки, то личность вашей сборки в целом изменилась. Разработчикам необходимо будет перестроить, чтобы ссылаться на вашу новую версию (если только вы не наложили некоторую политику "автоматического определения версий" на месте), и во время выполнения будут загружены только сборки с соответствующими номерами версий.
Это важно в моей среде, где нам нужен инкрементный, очень видимый номер версии для целей аудита, но мы не хотим заставлять разработчиков перестраивать или иметь много версий одновременно на производстве. В этом случае для вспомогательных изменений, совместимых с назад, мы обновляем версию файла, но не версию сборки.
Версии файлов используются только для целей отображения, тогда как версия сборки играет важную роль в поведении загрузки .NET.
Не совсем. Версия файла также важна для установщика Windows при обновлении существующей версии по сравнению с предыдущей версией.
В моем текущем приложении каждый проект VS имеет ссылку на исходный файл AssemblyBuildInfo, который имеет следующие атрибуты:
[assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyCompany("Acme Corporationy")]
[assembly: AssemblyCopyright("Copyright © 2009 Acme Corporation")]
Таким образом, все сборки в моем решении используют одну и ту же версию и информацию о компании (что означает, что если я должен ее изменить, я меняю ее только один раз). Исключая FileVersion, он автоматически устанавливается в AssemblyVersion.
@Adam: Вы меняете версию файла с каждой сборкой? Используете ли вы контроль версий (SYN или VSS) и используете эту информацию, чтобы связать источник с двоичными файлами?
Кажется, имеет смысл, что версия Assembly остается прежней. то есть "2.0.0.0". Это соответствует развертыванию продукта.
Версия файла изменяется в соответствии с версией исходного элемента управления. "2.0.The.revision" Это обеспечило бы ссылку из определенной dll (или exe) на источник, который ее построил.
Я написал сообщение в блоге об этой теме, которое может быть полезно сообществу http://blog.raffaeu.com/archive/2011/12/11/sharing-assembly-version-in-visual-studio-2010.aspx
Я сохраняю их одинаково. Но тогда у меня нет многоуровневых сборок, то есть когда число AssemblyVersion становится важным. Я использую кодировку даты в стиле Microsoft для своих номеров сборки, а не автоматически увеличивая (я не нахожу, сколько раз было построено что-то, что было важно).