Есть ли веские причины для совпадения AssemblyVersion и AssemblyFileVersion?

Gendarme имеет 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] иметь общий непустой префикс< /strong>, когда оба присутствуют в сборке.


.net attributes versioning assemblyinfo gendarme
person Community    schedule 17.01.2010    source источник

Ответы (3)


arrow_upward
9
arrow_downward

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

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

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

person Michael Stum    schedule 17.01.2010
comment
Я согласен с этим мнением: версия файла очень ценна для нескольких сборок, но между публичными выпусками. Как правило, вы никогда не меняете версию сборки более одного раза между публичными выпусками, но изо дня в день ваш отдел тестирования является лишь одним из примеров того, как вам нужен способ определить, из какой сборки взята конкретная DLL ... чтобы иметь возможность описательного журнала выдавать отчеты в этом случае. Поскольку (в идеале) все эти сборки (готовящиеся к выпуску) используют одну и ту же версию сборки, то файловая версия — правильный инструмент для их дифференциации. - person Adam; 20.06.2011

arrow_upward
4
arrow_downward

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

person Hans Passant    schedule 17.01.2010

arrow_upward
0
arrow_downward

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

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

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

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

person Community    schedule 18.01.2010