управление версиями сборок в .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 is предназначен для уникальной идентификации сборки индивидуальная сборка

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

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

этот номер версии хранится в ресурсе версии Win32 и может быть виден при просмотре страницы свойств Проводника Windows для сборки.

CLR не заботится и не исследует AssemblyFileVersion.

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

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

" например, версия 2.0 продукта может содержать несколько сборок; одна эти сборки помечены как версия 1.0, так как это новая сборка это не было отправлено в версии 1.0 тот же продукт. Как правило, вы устанавливаете основные и второстепенные части этой версии число представлять публичную версию вашего продукта. Тогда вы инкремент части сборки и ревизии каждый раз пакет полный продукт с все его сборка." - Jeffrey Richter, [CLR via C# (второе издание)] p. 57

среда CLR не заботится и не рассматривает AssemblyInformationalVersion.

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

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

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

путаница в том, что вся 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 изначально намеревалась быть немного более снисходительной к этому строгому соответствию полного AssemblyVersion, путем сопоставления только на основных и второстепенных частях версии:

" при загрузке сборки среда CLR автоматически найдет последнюю версию установленная версия обслуживания соответствует основной / минорной версии ассамблея запрашивается." - Jeffrey Richter, [CLR via C# (второе издание)] p. 56

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

"примечание: Я только что описал, как вы следует подумать о номерах версий. К сожалению, CLR не лечит номера версий таким образом. [в сетях 2.0], среда CLR обрабатывает номер версии как непрозрачное значение, и если сборка зависит от версии 1.2.3.4 другого сборка, CLR пытается загрузить версия 1.2.3.4 (только без привязки перенаправление на месте). Однако, Microsoft планирует изменить Погрузчик среды CLR в будущая версия так что он загружает последние сборка / ревизия для данного major / minor версия сборки. Например, о будущей версии среды CLR, если загрузчик пытается найти версию 1.2.3.4 сборки и версии 1.2.5.0 существует, загрузчик с автоматически забрать последнюю обслуживающая версия. Это будет очень добро пожаловать в загрузчик CLR-I потому что ждать нельзя." - Jeffrey Richter, [CLR via C# (второе издание)] 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 для сервисного выпуска, который должен быть обратно совместим.
• Do измените 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, компилятор добавляет его для вас, снимая часть "ревизии" вашего номера версии и оставляя основной.незначительный.строить.

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

AssemblyInformationalVersion - значение "версия продукта". AssemblyFileVersion - это значение "версия файла".

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

из них единственным, который абсолютно необходим .NET, является

стоит отметить еще кое-что:

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

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

2) AssemblyFileVersion - это простой текст. Он не должен соответствовать ограничениям схемы нумерации, которые делает AssemblyVersion (., если хотите. Ваша система сборки должна будет заполнить токены.

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

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

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

например AssemblyVersion 1.0.3.* упакованный с asp.net ядро dotnet-cli

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

производит пакет с версией 1.0.3-ки-7, который вы можете проверить с отражением через:

CustomAttributeExtensions.GetCustomAttribute<AssemblyInformationalVersionAttribute>(asm);

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