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

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

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

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

Путаница из-за того, должна ли вся AssemblyVersion соответствовать. (Да, это так.)

Существует небольшая путаница в отношении того, должно ли все AssemblyVersion быть точным совпадением для загрузки сборки. Некоторые люди ошибочно полагают, что только основные и второстепенные части AssemblyVersion должны совпадать, чтобы связывание было успешным. Это разумное предположение, однако в конечном итоге оно неверно (начиная с .NET 3.5), и это легко проверить для вашей версии 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, перекомпилироваться для новой версии!