В чем различия между AssemblyVersion, AssemblyFileVersion и AssemblyInformationalVersion?
Существует три атрибута версии сборки. Какие есть отличия? Это нормально, если я использую AssemblyVersion и игнорировать остальное?
MSDN говорит:
Определяет версию сборки.
Указывает компилятору использовать определенный номер версии для ресурса версии файла Win32. Версия файла Win32 не обязательно должна совпадать с номером версии сборки.
Определяет дополнительную информацию о версии для манифеста сборки.
Это продолжение к тому, каковы лучшие методы использования атрибутов сборки?
7 ответов
AssemblyVersion
Где будут смотреть другие сборки, которые ссылаются на вашу сборку. Если это число изменяется, другие сборки должны обновить свои ссылки на вашу сборку! AssemblyVersion необходимо.
Я использую формат: Major.minor. Это приведет к:
[assembly: AssemblyVersion("1.0")]
AssemblyFileVersion
Используется для развертывания. Вы можете увеличить это число для каждого развертывания. Используется программами установки. Используйте его, чтобы отметить сборки, которые имеют одинаковые AssemblyVersion, но генерируются из разных сборок.
В Windows это можно посмотреть в свойствах файла.
Если возможно, пусть он генерируется MSBuild. AssemblyFileVersion является необязательным. Если не указано, используется AssemblyVersion.
Я использую формат: major.minor.revision.build, где я использую ревизию для стадии разработки (Alpha, Beta, RC и RTM), пакеты обновления и исправления. Это приведет к:
[assembly: AssemblyFileVersion("1.0.3100.1242")]
AssemblyInformationalVersion
Версия продукта сборки. Это версия, которую вы будете использовать при общении с клиентами или для отображения на вашем сайте. Эта версия может быть строкой, например, "1.0 Release Candidate".
Анализ кода будет жаловаться на это (CA2243) - сообщается в Microsoft (не исправлено в 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 предназначен для однозначной идентификации сборки отдельной сборки
Как правило, вы вручную устанавливаете 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 любой сборки, которая на нее ссылается.
Это очень важно, поскольку это означает, что когда вы ссылаетесь на сборку со строгим именем, вы тесно связаны с конкретной версией AssemblyVersion этой сборки. Вся версия 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 via C# (Second Edition)] p. 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 via C# (Second Edition)] p. 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 (например,
Более того, он не подлежит замене подстановочным знаком, которым является AssemblyVersion. Если у вас просто есть значение "3.0.1.*" В AssemblyInfo.cs, это именно то, что будет отображаться в элементе "Другая информация о версии" -> "Версия файла".
3) Я не знаю, как влияет на установщик использование чего-либо, кроме числовых номеров версий файлов.
При изменении AssemblyVersion сборки, если она имеет строгое имя, ссылочные сборки необходимо перекомпилировать, иначе сборка не загружается! Если у него нет строгого имени, если оно явно не добавлено в файл проекта, оно не будет скопировано в выходной каталог при сборке, поэтому вы можете пропустить определенные сборки, особенно после очистки выходного каталога.