Я искал некоторые хорошие практики по именованию сборок и их версии. Как часто вы увеличиваете основные или второстепенные версии?
В некоторых случаях я видел выпуски, идущие прямо с версии 1.0 до 3.0. В других случаях он, похоже, застрял в версии 1.0.2.xxxx.
Это будет для общей сборки, используемой в нескольких проектах в компании. С нетерпением ждем хороших результатов.
Некоторая хорошая информация из эта статья в блоге Suzanne Cook на MSDN (опубликовано в 2003-05-30):
Когда менять файлы/версии сборки
Прежде всего, версии файлов и версии сборки не должны совпадать друг с другом. Я рекомендую, чтобы версии файлов изменялись с каждым строить. Но, не изменяйте версии сборки с каждой сборкой только так что вы можете сказать разницу между двумя версиями того же файл; используйте для этого версию файла. Принятие решения о замене сборки версии обсуждают типы построений: отправка и не отправка.
Non-Shipping Builds
В общем, я рекомендую сохранять версии сборки без доставки одинаково между сборками доставки. Эта позволяет избежать проблем с загрузкой жестко названных сборок из-за версии несовпадения. Некоторые люди предпочитают использовать политику издателя для перенаправления новых для каждой сборки. Я рекомендую однако, не связанные с доставкой сборки: он не избегает загрузки проблемы. Например, если партнер x-копирует ваше приложение, они могут не знать, устанавливать политику издателя. Затем ваше приложение будет разбито на их, даже если он отлично работает на вашей машине.Но, если есть случаи, когда разные приложения на одном и том же машине необходимо привязать к различным версиям вашей сборки, я рекомендуется предоставить эти сборки для разных версий сборки, чтобы правильный для каждого приложения можно использовать без использования LoadFrom/др.
Доставка сборки. Что касается того, есть ли хорошая идея изменить эту версию для сборки, она зависит от того, как вы хотите привязать работа для конечных пользователей. Вы хотите, чтобы эти сборки были бок о бок или на месте? Много ли изменений между двумя сборками? Они собирается сломать некоторых клиентов? Вам все равно, что это нарушает их (или вы хотите заставить пользователей использовать ваши важные обновления)? Если да, вы следует рассмотреть возможность увеличения версии сборки. Но затем снова, считают, что выполнение этого слишком много раз может привести к потере диска пользователей с устаревшими сборками.
При изменении версий сборки
Чтобы изменить версии с жесткой кодировкой на новую, я рекомендую установить переменную в версию в файле заголовка и замене жесткого кодирования в источниках на переменная. Затем запустите предварительный процессор во время сборки, чтобы вставить правильная версия. Я рекомендую менять версии сразу после отгрузки, не раньше, так что есть больше времени, чтобы ловить ошибки из-за изменение.
Один из способов определить ваше управление версиями - дать семантический смысл каждой части:
Вышеприведенное является просто примером - вы бы хотели определить правила, которые имеют смысл для вас. Но пользователям очень приятно быстро узнать, ожидаются ли несовместимости, просто взглянув на версию.
О, и не забудьте опубликовать правила, которые вы придумали, чтобы люди знали, чего ожидать.
Семантическая версия имеет набор руководств и правил относительно того, как применять это (и когда). Очень просто следовать, и он просто работает.
Первое, что я бы рекомендовал, - это ознакомиться с различиями между версией Assembly и версией File. К сожалению,.NET имеет тенденцию рассматривать их как то же самое, когда дело доходит до файлов AssemblyInfo, поскольку обычно он помещает AssemblyVersion и позволяет FileVersion по умолчанию иметь одинаковое значение.
Поскольку вы сказали, что это совместная сборка, я предполагаю, что вы имеете в виду, что она делится на двоичном уровне (не включая проект в различных решениях). Если в этом случае вы хотите быть очень преднамеренным в изменении версии сборки, это то, что .NET использует для сильного имени сборки (чтобы вы могли поместить ее в GAC), а также составляло "полное имя сборки". Когда версия сборки изменяется, она может иметь нарушения для приложений, которые ее используют, без добавления записей переадресации сборки в файле app.config.
Что касается именования, я думаю, что это зависит от того, какие правила именования вашей компании (если есть) и цель библиотеки. Для exmaple, если эта библиотека предоставляет функциональность "core" (или системного уровня), которая не является специфической для какого-либо конкретного продукта или деловой линии, вы можете назвать ее как:
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