Я ищу хорошие практики по именованию сборок и их версии. Как часто вы увеличиваете старшие или второстепенные версии?
В некоторых случаях я видел релизы, идущие прямо с версии 1.0 на 3.0. В других случаях кажется, что он застрял на версии 1.0.2.xxxx.
Это будет для общей сборки, используемой в нескольких проектах в компании. С нетерпением жду хороших отзывов.
Некоторая полезная информация из этой статьи в блоге Сюзанны Кук. в MSDN (опубликовано 30 мая 2003 г.):
Когда менять версию файла / сборки
Во-первых, версии файлов и сборки могут не совпадать. Я рекомендую менять версии файлов с каждой сборкой. Но не меняйте версии сборки с каждой сборкой только для того, чтобы вы могли различить две версии одного и того же файла; используйте для этого версию файла. Чтобы решить, когда менять версии сборки, необходимо обсудить типы сборок, которые следует учитывать: отгрузка и отгрузка.
Сборки, не предназначенные для доставки
Как правило, я рекомендую сохранять версии сборок, не предназначенных для доставки, одинаковыми между отправляемыми сборками. Это позволяет избежать проблем с загрузкой сборок со строгими именами из-за несоответствия версий. Некоторые люди предпочитают использовать политику издателя для перенаправления новых версий сборок для каждой сборки. Однако я не рекомендую этого делать для сборок, не поставляемых в продажу: это не позволяет избежать всех проблем с загрузкой. Например, если партнер делает ксерокопирование вашего приложения, он может не знать, что нужно установить политику издателя. Тогда ваше приложение будет сломано для них, даже если оно отлично работает на вашем компьютере.Но если есть случаи, когда разные приложения на одном компьютере должны быть привязаны к разным версиям вашей сборки, я рекомендую предоставить этим сборкам разные версии сборки, чтобы можно было использовать правильную версию для каждого приложения без использования LoadFrom / etc.
Доставка сборок
Что касается того, стоит ли менять эту версию для доставки сборок, это зависит от того, как вы хотите, чтобы привязка работала для конечных пользователей. Вы хотите, чтобы эти сборки располагались бок о бок или на месте? Есть ли много изменений между двумя сборками? Собираются ли они сломать некоторых клиентов? Вам небезразлично, что это их сломает (или вы хотите заставить пользователей использовать ваши важные обновления)? Если да, вам следует рассмотреть возможность увеличения версии сборки. Но, опять же, учтите, что повторение этого слишком много раз может засорять диск пользователя устаревшими сборками.Когда вы меняете версии сборки
Чтобы изменить жестко запрограммированные версии на новую, я рекомендую установить переменную для версии в файле заголовка и заменить жесткое кодирование в источниках на эту переменную. Затем запустите препроцессор во время сборки, чтобы установить правильную версию. Я рекомендую менять версии сразу после доставки, а не прямо перед ним, чтобы было больше времени на обнаружение ошибок, связанных с изменением.
В семантическом управлении версиями есть набор руководящих принципов и правил относительно того, как это применять (и когда). Очень просто следовать, и это просто работает.
Первое, что я бы порекомендовал, - это ознакомиться с различиями между версией сборки и версией файла. К сожалению, .NET имеет тенденцию рассматривать их как то же самое, когда дело доходит до файлов AssemblyInfo, поскольку обычно ставит только AssemblyVersion и позволяет FileVersion по умолчанию использовать то же значение.
Поскольку вы сказали, что это общая сборка, я предполагаю, что вы имеете в виду, что она используется на двоичном уровне (не путем включения проекта в различные решения). Если это так, вы хотите быть очень осторожными при изменении версии сборки, поскольку это то, что .NET использует для строгого имени сборки (чтобы вы могли поместить ее в GAC), а также составляет «полное имя сборки». Когда версия сборки изменяется, она может иметь критические изменения для приложений, которые ее используют, без добавления записей перенаправления сборки в файл app.config.
Что касается именования, я думаю, это зависит от правил именования вашей компании (если они есть) и цели библиотеки. Например, если эта библиотека обеспечивает «базовую» (или системную) функциональность, которая не является специфической для какого-либо конкретного продукта или направления бизнеса, вы можете назвать ее следующим образом:
CompanyName.Framework.Core
если это часть более крупной библиотеки, или просто
CompanyName.Shared
CompanyName.Core
CompanyName.Framework
Что касается того, когда увеличивать номера версий, это все еще довольно субъективно и зависит от того, что вы считаете каждой частью номера сборки для представления. Схема Microsoft по умолчанию - Major.Minor.Build.Revision, но это не значит, что вы не можете придумать свои собственные определения. Самое главное - быть последовательным в своей стратегии и убедиться, что определения и правила имеют смысл для всех ваших продуктов.
Почти во всех схемах версий, которые я видел, первые две части - это Major.Minor. Номер основной версии обычно увеличивается, когда есть большие изменения и / или критические изменения, в то время как дополнительный номер версии обычно увеличивается, чтобы указать, что что-то измененное, которое произошло, не было критическим изменением. Два других числа значительно более субъективны и могут быть «сборкой» (которая часто является значением серийной даты или последовательно обновляемым номером, который меняется каждый день) и «ревизией» или номером патча. Я также видел их перевернутыми (давая Major.Minor.Revision.Build), где build - это последовательно увеличивающееся число из автоматической системы сборки.
Помните, что основная и дополнительная версии сборки используются в качестве номера версии библиотеки типов при экспорте сборки.
Наконец, взгляните на некоторые из этих ресурсов для получения дополнительной информации:
http://msdn.microsoft.com/en-us/library/51ket42z.aspx
http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.aspx
http://blogs.msdn.com/suzcook/archive/2003/05/29/57148.aspx
