В чем разница между FileVersion и ProductVersion в DLL?

В чем разница между FileVersion и ProductVersion в DLL?

В частности, используется ли один для сильной привязки, а другой информационный?

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

Изменить: Ричард ответил на ту часть, которую я пропустил в исходном вопросе. Это версия сборки, которую я хочу контролировать вручную (увеличивая с изменениями интерфейса), в то время как это версия файла, которую я хочу, чтобы моя система CI автоматически увеличивалась с каждой сборкой. Спасибо.


.net versioning
person Peter Drier    schedule 15.04.2009    source источник
comment
Проверьте stackoverflow.com/a/802038 для получения некоторой интересной информации о AssemblyVersion, AssemblyFileVersion и AssemblyInformationalVersion (т.е. версия сборки, версия файла и версия продукта ).   -  person user276648    schedule 11.12.2012

Ответы (3)


arrow_upward
26
arrow_downward

Ни то, ни другое не используется для строгой привязки (аспект версии полного / строгого имени определяется атрибутом AssemblyVersion).

И версия файла (из атрибута AssemblyFileVersion), и версия продукта (из атрибута AssemblyInformationalVersion) вносят вклад в ресурс версии (как видно в свойствах файла проводника).

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

Приложение: почему они должны отличаться? Ответ: Из-за требований к версии. Сохранение той же версии сборки означает, что обновленная версия (с более высокой версией файла) будет привязана без изменений. Это имеет большое влияние на сериализацию (например, постоянные рабочие процессы).

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

person Richard    schedule 15.04.2009
comment
Итак, почему мы хотим, чтобы эти трое были разными на практике? Imo AssemblyVersion должна править, не так ли? - person Peter Lillevold; 15.04.2009
comment
@Peter: хороший вопрос ... расширен несколькими краткими комментариями, но для этого действительно нужен отдельный вопрос. - person Richard; 15.04.2009

arrow_upward
35
arrow_downward

Файлы распространяются как часть более крупного проекта. Файл с индивидуальной версией сборки x может распространяться как часть версии проекта y.

Для уточнения: A.exe с версией продукта 1.1 поставляется с файлами B.dll и C.dll. Все начинаются с совпадающих версий продукта и файлов. Затем кто-то находит в продукте серьезную ошибку. Разработчик смотрит на это и выпускает исправление, которое обновляет только B.dll. Теперь версия продукта, вероятно, также обновляется до 1.1.1, чтобы учесть незначительное исправление. Версия файла B.dll также будет 1.1.1. Но A.exe и C.dll не изменились, поэтому их версия файла все еще может быть 1.1.

person Joel Coehoorn    schedule 15.04.2009
comment
Спасибо. Возможно, это считается общеизвестным, но было бы неплохо, если бы об этом упомянули в документации MS. - person iforce2d; 02.12.2012
comment
Итак, если есть только один исполняемый файл без других DLL, следует ли мне сохранять версию файла и версию продукта одинаковыми и обновлять их постепенно с каждым новым выпуском? - person Dan W; 26.03.2015

arrow_upward
7
arrow_downward

Есть еще одно различие между этими двумя: в версии файла вам разрешено использовать только целые числа, равные или больше 0 в частях версии.

В версии продукта вам разрешено использовать любой текст, он выдаст предупреждение, если не будет преобразован в числа, но это предупреждение, согласно msdn, безвредно.

Теперь почему вы должны использовать в версии не только числа?
Что ж, согласно семантическому управлению версиями (semver.org) версия выглядит так: [Major]. [Minor]. [Patch] и в патче вам разрешено использовать :

  • метаданные предварительной версии после тире, например 1.2.1-beta
  • построить метаданные после плюса, например короткий хеш из git 1.2.1 + f0f0f0f
person Giedrius    schedule 25.02.2016
comment
Умм .. Эта функция немного противоречит ответу Джоэла. Эта версия продукта должна быть более стабильной, а версия файла - более динамичной ... - person joe; 14.09.2020