Существуют ли веские причины для совпадения AssemblyVersion и AssemblyFileVersion?

Question

Жандарм имеет AvoidAssemblyVersionMismatchRule со следующим описанием:

Это правило проверяет, что [AssemblyVersion] соответствует [AssemblyFileVersion], когда оба присутствуют внутри сборки. Наличие разных номеров версий в обоих атрибутах может привести к путанице после развертывания приложения.

Например, это правило будет предупреждать Microsoft System.dll, которая имеет следующие атрибуты:

[assembly: AssemblyVersion("2.0.0.0")]
[assembly: AssemblyFileVersion("2.0.50727.3053")]

Я не согласен с правилом Жандарма. Следуя этому, вы не сможете использовать схему управления версиями, аналогичную используемой Microsoft, то есть

• обновление AssemblyFileVersion при каждой сборке,
• изменить AssemblyVersion только в общедоступном интерфейсе или иными существенными изменениями
• убедитесь, что AssemblyVersion и AssemblyFileVersion имеют общий префикс

и я думаю, что эта схема управления версиями является той причиной, по которой было сделано возможным провести различие между AssemblyVersion и AssemblyFileVersion.

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

Если на самом деле нет веских причин, я скоро предложу разработчикам жандарма изменить правило на

Это правило проверяет, что [AssemblyVersion] и [AssemblyFileVersion] имеют общий непустой префикс , когда оба присутствуют внутри сборки.

Answer 1

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

AssemblyVersion больше похожа на «версию всего вашего приложения», а FileVersion - это версия отдельного файла.Если ваше приложение имеет несколько сборок, которые по какой-либо причине имеют разные циклы обновления (например, плагины, которые обновляются отдельно, но для которых требуется определенный основной выпуск основного приложения), тогда вы можете назначить каждому отдельную FileVersion, но иметь общую AssemblyVersion.

Кроме того, иногда действительно неудобно обновлять AssemblyVersion (например, рабочие процессы SharePoint и веб-части представляют собой PITA для обновления, поскольку они ожидают указанного AssemblyVersion), поэтому там FileVersion часто используется в качестве реальной версии.

Answer 2

Согласен, это глупое правило. Вы не могли бы развернуть обновление исправления ошибки для сборки со строгим именем, когда вы следуете за ней. В противном случае есть несколько причин не делать их одинаковыми, если вам действительно нужно изменить [AssemblyVersion]. Может быть, вы не должны использовать этот инструмент, когда исправляете ошибки. Иронический.

Answer 3

Я думаю, что правило имеет смысл во многих сценариях, поскольку .NET Framework, по сути, считает две сборки с одинаковой AssemblyVersion взаимозаменяемыми.

Так, например, старая версия в Кэше загрузок не будет автоматически перезаписана новой версией, отличающейся только в AssemblyFileVersion.

Это может сбить с толку среднего разработчика, отсюда и правило.

Конечно, если вы знаете, что делаете, и понимаете компромиссы, вы можете игнорировать правило.