Существует три атрибута версии сборки. Какие есть отличия? Это нормально, если я использую AssemblyVersionи игнорирую все остальное?

MSDN говорит:

• AssemblyVersion :

  Определяет версию сборки, которая приписывается.

• AssemblyFileVersion :

  Указывает компилятору использовать определенный номер версии для ресурса версии файла Win32. Версия файла Win32 не обязательно должна совпадать с номером версии сборки.

• AssemblyInformationalVersion :

  Определяет дополнительную информацию о версии для манифеста сборки.

Это продолжение к тому, каковы лучшие практики использования атрибутов сборки?

AssemblyVersion

Где будут смотреть другие сборки, которые ссылаются на вашу сборку. Если это число меняется, другие сборки должны обновить свои ссылки на вашу сборку! Обновляйте только эту версию, если она нарушает обратную совместимость. AssemblyVersionТребуется.

Я использую формат: Major.minor . Это приведет к:

[assembly: AssemblyVersion("1.0")]

Если вы строго следите за SemVer, то это означает, что вы обновляетесь только при значительных изменениях, например, 1.0, 2.0, 3.0 и т. Д.

AssemblyFileVersion

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

В Windows это можно посмотреть в свойствах файла.

AssemblyFileVersion является необязательным. Если не указано, используется AssemblyVersion.

Я использую формат: major.minor.patch.build , где я следую SemVer для первых трех частей и использую номер сборки сервера сборки для последней части (0 для локальной сборки). Это приведет к:

[assembly: AssemblyFileVersion("1.3.2.254")]

Помните, что System.Version называет эти части как major.minor.build.revision!

AssemblyInformationalVersion

Версия продукта сборки. Это версия, которую вы будете использовать при общении с клиентами или для отображения на вашем сайте. Эта версия может быть строкой, например, « 1.0 Release Candidate ».

Это AssemblyInformationalVersionнеобязательно. Если не указан, используется AssemblyFileVersion.

Я использую формат: major.minor [.patch] [revision as string] . Это приведет к:

[assembly: AssemblyInformationalVersion("1.0 RC1")]

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

Вот три основных атрибута сборки, связанных с версией:

// Assembly mscorlib, Version 2.0.0.0
[assembly: AssemblyFileVersion("2.0.50727.3521")]
[assembly: AssemblyInformationalVersion("2.0.50727.3521")]
[assembly: AssemblyVersion("2.0.0.0")]

Условно четыре части версии называются Основная версия , Малая версия , Сборка и Редакция .

AssemblyFileVersionПредназначен для однозначной идентификации сборки из индивидуальной сборки

Обычно вы вручную устанавливаете Major и Minor AssemblyFileVersion для отображения версии сборки, а затем увеличиваете Build и / или Revision каждый раз, когда ваша система сборки компилирует сборку. AssemblyFileVersion должна позволять вам однозначно идентифицировать сборку сборки, чтобы вы могли использовать ее в качестве отправной точки для устранения любых проблем.

В моем текущем проекте у сервера сборки есть код списка изменений из нашего репозитория исходного кода в части Build и Revision AssemblyFileVersion. Это позволяет нам напрямую сопоставлять сборку с ее исходным кодом для любой сборки, сгенерированной сервером сборки (без необходимости использовать метки или ветви в управлении исходным кодом или вручную хранить какие-либо записи выпущенных версий).

Этот номер версии хранится в ресурсе версии Win32, и его можно увидеть при просмотре страниц свойств Windows Explorer для сборки.

CLR не заботится и не проверяет AssemblyFileVersion.

AssemblyInformationalVersionПредназначено для представления версии всей продукции

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

«Например, версия 2.0 продукта может содержать несколько сборок; одна из этих сборок помечена как версия 1.0, поскольку это новая сборка, которая не поставлялась в версии 1.0 того же продукта. Как правило, основные и второстепенные части этого номера версии задаются как открытая версия вашего продукта. Затем вы увеличиваете части сборки и ревизии каждый раз, когда упаковываете полный продукт со всеми его сборками ». - Джеффри Рихтер, [CLR через C # (второе издание)] с. 57

CLR не заботится и не изучает AssemblyInformationalVersion.

Это AssemblyVersionединственная версия, о которой заботится CLR (но она заботится обо всем AssemblyVersion)

AssemblyVersion используется CLR для привязки к строго именованным сборкам. Он хранится в таблице метаданных манифеста AssemblyDef собранной сборки и в таблице AssemblyRef любой сборки, которая на нее ссылается.

Это очень важно, потому что это означает, что когда вы ссылаетесь на сборку со строгим именем, вы тесно связаны с конкретной версией Assembly для этой сборки. Вся AssemblyVersion должна точно соответствовать для успешного связывания. Например, если вы ссылаетесь на версию 1.0.0.0 сборки со строгим именем во время сборки, но во время выполнения доступна только версия 1.0.0.1 этой сборки, связывание завершится ошибкой! (Затем вам придется обойти это, используя перенаправление привязки сборки .)

Путаница в том, должно ли все AssemblyVersionсовпадать. (Да, это так.)

Существует небольшая путаница вокруг того, должно ли полное AssemblyVersion быть точным совпадением для загрузки сборки. Некоторые люди ошибочно полагают, что только основные и второстепенные части AssemblyVersion должны совпадать, чтобы связывание было успешным. Это разумное предположение, однако в конечном итоге оно неверно (начиная с .NET 3.5), и это легко проверить для вашей версии CLR. Просто выполните этот пример кода .

На моей машине происходит сбой загрузки второй сборки, и последние две строки журнала Fusion ясно показывают, почему:

.NET Framework Version: 2.0.50727.3521
---
Attempting to load assembly: Rhino.Mocks, Version=3.5.0.1337, Culture=neutral, PublicKeyToken=0b3305902db7183f
Successfully loaded assembly: Rhino.Mocks, Version=3.5.0.1337, Culture=neutral, PublicKeyToken=0b3305902db7183f
---
Attempting to load assembly: Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f
Assembly binding for  failed:
System.IO.FileLoadException: Could not load file or assembly 'Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, 
PublicKeyToken=0b3305902db7183f' or one of its dependencies. The located assembly's manifest definition 
does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f'

=== Pre-bind state information ===
LOG: User = Phoenix\Dani
LOG: DisplayName = Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f
 (Fully-specified)
LOG: Appbase = [...]
LOG: Initial PrivatePath = NULL
Calling assembly : AssemblyBinding, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v2.0.50727\config\machine.config.
LOG: Post-policy reference: Rhino.Mocks, Version=3.5.0.1336, Culture=neutral, PublicKeyToken=0b3305902db7183f
LOG: Attempting download of new URL [...].
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

Я думаю, что источником этой путаницы, вероятно, является то, что Microsoft изначально намеревалась быть немного более снисходительной в этом строгом сопоставлении полной версии AssemblyVersion, сопоставляя ее только в частях Major и Minor версии:

«При загрузке сборки CLR автоматически найдет последнюю установленную версию обслуживания, которая соответствует основной / вспомогательной версии запрашиваемой сборки». - Джеффри Рихтер, [CLR через C # (второе издание)] с. 56

Это было поведение в бета-версии 1 CLR 1.0, однако эта функция была удалена до выпуска 1.0 и не смогла вновь появиться в .NET 2.0:

«Примечание: я только что описал, как вы должны думать о номерах версий. К сожалению, CLR не обрабатывает номера версий таким образом. [В .NET 2.0] CLR обрабатывает номер версии как непрозрачное значение, и, если сборка зависит от версии 1.2.3.4 другой сборки, CLR пытается загрузить только версию 1.2.3.4 (если не существует перенаправления привязки ). Однако Microsoft планирует изменить загрузчик CLR в будущей версии, чтобы он загружал последнюю сборку / ревизию для данной основной / вспомогательной версии сборки, Например, в будущей версии CLR, если загрузчик пытается найти версию 1.2.3.4 сборки и существует версия 1.2.5.0, загрузчик автоматически выбирает последнюю версию обслуживания. Это будет очень приятное изменение в загрузчике CLR - я, например, не могу ждать ». - Джеффри Рихтер, [CLR через C # (второе издание)] с. 164 (Акцент мой)

Поскольку это изменение до сих пор не реализовано, я думаю, что можно с уверенностью предположить, что Microsoft отреагировала на это намерение, и, возможно, уже слишком поздно, чтобы изменить это сейчас. Я пытался искать в Интернете, чтобы узнать, что случилось с этими планами, но я не мог найти никаких ответов. Я все еще хотел докопаться до сути.

Поэтому я написал Джеффу Рихтеру по электронной почте и прямо спросил его - я подумал, что кто-нибудь знает, что случилось, это будет он.

В течение 12 часов он ответил не менее субботним утром и пояснил, что в загрузчике .NET 1.0 Beta 1 реализован механизм «автоматического отката», позволяющий собирать последние доступные сборки и ревизии сборки, но такое поведение было возвращен до .NET 1.0 поставляется. Позже было задумано возродить это, но оно не вошло до того, как CLR 2.0 был выпущен. Затем появился Silverlight, который стал приоритетным для команды CLR, поэтому эта функциональность была отложена еще больше. Между тем, большинство людей, которые были рядом во времена CLR 1.0 Beta 1, уже ушли, поэтому маловероятно, что это увидит свет, несмотря на всю тяжелую работу, которая уже была проделана.

Нынешнее поведение, похоже, здесь, чтобы остаться.

Стоит также отметить, что из моего обсуждения с Джеффом, AssemblyFileVersion был добавлен только после удаления механизма «автоматического отката» - поскольку после 1.0 Beta 1 любое изменение в AssemblyVersion было критическим изменением для ваших клиентов, тогда негде безопасно хранить ваш номер сборки. AssemblyFileVersion - это безопасное убежище, поскольку оно никогда не проверяется автоматически CLR. Может быть, так будет понятнее, имея два отдельных номера версий с разными значениями, вместо того, чтобы пытаться сделать это разделение между основными / второстепенными (разрывными) и сборочными / ревизионными (неразрывными) частями AssemblyVersion.

Итог: тщательно продумайте, когда вы меняете AssemblyVersion

Мораль такова, что если вы отправляете сборки, на которые будут ссылаться другие разработчики, вам нужно быть предельно осторожным, когда вы изменяете (и не изменяете) AssemblyVersion этих сборок. Любые изменения в AssemblyVersion будут означать, что разработчикам приложений придется либо перекомпилироваться с новой версией (чтобы обновить эти записи AssemblyRef), либо использовать перенаправления привязки сборки, чтобы вручную переопределить привязку.

• Не изменяйте AssemblyVersion для сервисного выпуска, который предназначен для обратной совместимости.
• Как изменить AssemblyVersion для выпуска , что вы знаете , имеют отличия.

Просто взгляните на атрибуты версии в mscorlib:

// Assembly mscorlib, Version 2.0.0.0
[assembly: AssemblyFileVersion("2.0.50727.3521")]
[assembly: AssemblyInformationalVersion("2.0.50727.3521")]
[assembly: AssemblyVersion("2.0.0.0")]

Обратите внимание, что это AssemblyFileVersion, которая содержит всю интересную информацию об обслуживании (это версия Revision этой версии, которая сообщает вам, какой пакет обновления вы используете), в то время как AssemblyVersion исправлена ​​на скучной старой версии 2.0.0.0. Любое изменение в AssemblyVersion заставит каждое приложение .NET, ссылающееся на mscorlib.dll, перекомпилироваться для новой версии!

AssemblyVersionв значительной степени остается внутренним для .NET, в то время AssemblyFileVersionкак Windows видит это. Если вы перейдете к свойствам сборки, AssemblyFileVersionнаходящейся в каталоге, и перейдете на вкладку версии, то это то, что вы увидите вверху. Если вы сортируете файлы по версии, это то, что используется Explorer.

AssemblyInformationalVersionКарты в «Версии продукта» и предназначается , чтобы быть чисто «человеком используемым».

AssemblyVersionконечно, самое главное, но я бы тоже не стал пропускать AssemblyFileVersion. Если вы не предоставите AssemblyInformationalVersion, компилятор добавит его для вас, убрав часть «revision» номера вашей версии и оставив Major.minor.build.

AssemblyInformationalVersionи AssemblyFileVersionотображаются, когда вы просматриваете информацию «Версия» в файле через проводник Windows, просматривая свойства файла. Эти атрибуты фактически компилируются в VERSION_INFOресурс, который создается компилятором.

AssemblyInformationalVersionявляется значением «Версия продукта». AssemblyFileVersionзначение версии файла

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

Из них единственным, который абсолютно необходим .NET, является AssemblyVersionатрибут. К сожалению, это может также вызвать большинство проблем, когда оно меняется без разбора, особенно если вы хорошо называете свои сборки.

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

Например, AssemblyVersion версии 1.0.3. * В комплекте с ядром asp.net dotnet-cli

dotnet pack --version-suffix ci-7 src/MyProject

Создает пакет с версией 1.0.3-ci-7, который вы можете проверить с помощью отражения:

CustomAttributeExtensions.GetCustomAttribute<AssemblyInformationalVersionAttribute>(asm);

Стоит отметить некоторые другие вещи:

1) Как показано в диалоговом окне «Свойства проводника Windows» для сгенерированного файла сборки, есть два места, называемые «Версия файла». В заголовке диалогового окна отображается AssemblyVersion, а не AssemblyFileVersion.

В разделе Информация о другой версии есть еще один элемент, который называется «Версия файла». Здесь вы можете увидеть, что было введено как AssemblyFileVersion.

2) AssemblyFileVersion - это просто текст. Он не должен соответствовать ограничениям схемы нумерации, которые делает AssemblyVersion (например, <build> <65K). Это может быть 3.2. <Release tag text>. <Datetime>, если хотите. Ваша система сборки должна будет заполнить токены.

Более того, он не подлежит замене подстановочным знаком, которым является AssemblyVersion. Если у вас просто есть значение «3.0.1. *» В AssemblyInfo.cs, это именно то, что будет отображаться в элементе «Другая информация о версии» -> «Версия файла».

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

При изменении AssemblyVersion сборки, если она имеет строгое имя, ссылочные сборки необходимо перекомпилировать, иначе сборка не загружается! Если у него нет строгого имени, если оно явно не добавлено в файл проекта, оно не будет скопировано в выходной каталог при сборке, поэтому вы можете пропустить определенные сборки, особенно после очистки выходного каталога.