Есть ли веские причины, позволяющие совместить 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] имеют общий, непустой префикс, если оба присутствуют внутри сборки.

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

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

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

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