Есть ли веские причины для того, чтобы позволить 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 взаимозаменяемыми.

Так, например, старая версия, находящаяся в Download Cache, не будет автоматически перезаписана новой версией, отличающейся только версией AssemblyFileVersion.

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

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