Управление версиями сборок в .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, перекомпилироваться для новой версии!