В чем различия между AssemblyVersion, AssemblyFileVersion и AssemblyInformationalVersion?
https://stackoverflow.com/questions/64602
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Существует три атрибута версии сборки.В чем заключаются различия?Это нормально, если я использую AssemblyVersion и игнорировать все остальное?
MSDN говорит:
-
Указывает версию приписываемой сборки.
-
Указывает компилятору использовать определенный номер версии для ресурса версии файла Win32.Версия файла Win32 не обязательно должна совпадать с номером версии сборки.
Ассемблерная информационная версия:
Определяет дополнительную информацию о версии для манифеста сборки.
Это продолжение Каковы наилучшие методы использования атрибутов сборки?
Решение
Ассемблерная версия
Куда будут выглядеть другие сборки, ссылающиеся на вашу сборку.Если это число изменится, другим сборкам придется обновить свои ссылки на вашу сборку!Тот Самый AssemblyVersion требуется.
Я использую следующий формат: мажор.минор.Это привело бы к:
[assembly: AssemblyVersion("1.0")]
Изменение файла сборки
Используется для развертывания.Вы можете увеличивать это число при каждом развертывании.Он используется программами установки.Используйте его, чтобы пометить сборки, которые имеют одинаковый AssemblyVersion, но генерируются из разных сборок.
В Windows это можно просмотреть в свойствах файла.
Если возможно, пусть он будет сгенерирован MSBuild.AssemblyFileVersion является необязательным.Если не задано, используется AssemblyVersion.
Я использую следующий формат: основная.незначительная.доработка.сборка, где я использую версии на стадии разработки (альфа, бета, RC и RTM), пакеты обновления и горячие исправления.Это привело бы к:
[assembly: AssemblyFileVersion("1.0.3100.1242")]
Ассемблерная информационная версия
Версия продукта в сборе.Это версия, которую вы бы использовали при общении с клиентами или для показа на вашем веб-сайте.Эта версия может быть строкой, например 'Кандидат на выпуск 1.0'.
Анализ кода будет жаловаться на это (CA2243) -- передано в Корпорацию Майкрософт (не исправлено в VS2013).
Тот Самый AssemblyInformationalVersion является необязательным.Если не задано, используется AssemblyFileVersion.
Я использую следующий формат: major.minor [редакция в виде строки].Это привело бы к:
[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 предназначен для однозначной идентификации сборки индивидуальная сборка
Обычно вы вручную устанавливаете основную и второстепенную AssemblyFileVersion для отражения версии сборки, затем увеличиваете сборку и / или ревизию каждый раз, когда ваша система сборки компилирует сборку.AssemblyFileVersion должен позволять вам однозначно идентифицировать сборку сборки, чтобы вы могли использовать ее в качестве отправной точки для отладки любых проблем.
В моем текущем проекте у нас есть сервер сборки, который кодирует номер списка изменений из нашего репозитория системы управления версиями в части сборки и ревизии AssemblyFileVersion.Это позволяет нам напрямую сопоставлять сборку с ее исходным кодом для любой сборки, сгенерированной сервером сборки (без необходимости использовать метки или ветви в системе управления версиями или вручную сохранять какие-либо записи о выпущенных версиях).
Этот номер версии хранится в ресурсе версии Win32 и его можно увидеть при просмотре страниц свойств сборки в проводнике Windows.
Среда CLR не заботится о AssemblyFileVersion и не проверяет его.
Тот Самый AssemblyInformationalVersion предназначен для представления версии всего вашего продукта
AssemblyInformationalVersion предназначена для обеспечения согласованного управления версиями всего продукта, который может состоять из множества сборок, которые имеют независимые версии, возможно, с различными политиками управления версиями, и потенциально разрабатываются разрозненными командами.
“Например, версия 2.0 продукта может содержать несколько сборок;одна из этих сборок помечена как версия 1.0, поскольку это новая сборка , которая не поставлялась в версии 1.0 того же продукта.Как правило, вы задаете основную и второстепенную части этой версии номер для обозначения общедоступной версии вашего продукта.Тогда вы приращения сборка и доработка деталей каждый раз упаковка готового продукта с все свои сборки”. — Джеффри Рихтер, [CLR с помощью C# (второе издание)] п.57
Среда CLR не заботится о AssemblyInformationalVersion и не проверяет ее.
Тот Самый AssemblyVersion это единственная версия, о которой заботится среда CLR (но она заботится обо всем AssemblyVersion)
AssemblyVersion используется CLR для привязки к сборкам со строгими именами.Он хранится в таблице метаданных манифеста AssemblyDef созданной сборки и в таблице AssemblyRef любой сборки, которая ссылается на него.
Это очень важно, потому что это означает, что когда вы ссылаетесь на сборку со строгим именем, вы жестко привязаны к определенной AssemblyVersion этой сборки.Для успешного выполнения привязки вся AssemblyVersion должна точно совпадать.Например, если вы ссылаетесь на версию 1.0.0.0 сборки со строгим именем во время сборки, но во время выполнения доступна только версия 1.0.0.1 этой сборки, привязка завершится ошибкой!(Затем вам придется обойти это, используя Перенаправление привязки сборки.)
Путаница по поводу того, является ли вся AssemblyVersion должно совпадать.(Да, это так.)
Существует небольшая путаница в отношении того, должна ли вся AssemblyVersion точно совпадать для загрузки сборки.Некоторые люди ошибочно полагают, что для успешного связывания должны совпадать только основная и второстепенная части AssemblyVersion.Это разумное предположение, однако оно в конечном счете неверно (начиная с .NET 3.5), и проверить это для вашей версии CLR тривиально.Просто выполните этот пример кода.
На моей машине происходит сбой при загрузке второй сборки, и из последних двух строк журнала слияния совершенно ясно, почему:
.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 изначально намеревалась быть немного более снисходительной к этому строгому соответствию полной версии Assembly, сопоставляя только основные и второстепенные версии:
“При загрузке сборки среда 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 содержит всю интересную информацию об обслуживании (это часть редакции этой версии, которая сообщает вам, какой пакет обновления вы используете), в то время как 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 assembly, чтобы знать, какую версию сборки загружать / привязывать во время выполнения.
Из них единственным, который абсолютно необходим .NET, является AssemblyVersion атрибут.К сожалению, это также может вызвать наибольшее количество проблем, когда оно изменяется без разбора, особенно если вы строго указываете имена своих сборок.
Чтобы сохранить актуальность этого вопроса, стоит подчеркнуть, что AssemblyInformationalVersion используется NuGet и отражает версия пакета включая любой предрелизный суффикс.
Например, версия Assembly версии 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> < 65 Тысяч, например).Это может быть 3.2.<release tag="" text="">.<datetime>, если хотите.Ваша система сборки должна будет заполнить эти токены.
Более того, он не подлежит замене подстановочного знака, которым является AssemblyVersion.Если у вас просто есть значение "3.0.1.*" в AssemblyInfo.cs, это именно то, что будет отображаться в элементе Другая информация о версии-> Версия файла.
3) Однако я не знаю, как повлияет на установщик использование чего-то другого, кроме числовых номеров версий файлов.
При изменении AssemblyVersion сборки, Если у нее строгое имя, ссылающиеся сборки необходимо перекомпилировать, иначе сборка не загружается!Если у него нет строгого имени, если оно явно не добавлено в файл проекта, оно не будет скопировано в выходной каталог при сборке, поэтому вы можете пропустить зависимые сборки, особенно после очистки выходного каталога.
