Как лучше всего использовать атрибуты управления версиями сборки?
Атрибуты AssemblyVersion и AssemblyFileVersion - это встроенный способ обработки номеров версий для сборок .NET. Хотя фреймворк предоставляет возможность автоматически определять наименее значимые части номера версии (сборка и редакция, в терминах Microsoft), я считаю этот метод довольно слабым, и, без сомнения, у него есть много других.
Итак, я хотел бы спросить, какие способы были определены для того, чтобы номера версий лучше всего отражали фактическую версию проекта? У вас есть сценарий предварительной сборки, который устанавливает часть версии на дату и время или версию репозитория для вашей рабочей копии проекта? Вы просто используете автоматическую генерацию, предоставляемую фреймворком? Или что-то другое? Как лучше всего управлять версиями сборок / файлов?
Ответы 8
Наши сценарии сборки вводят номер набора изменений из TFS в версию. Таким образом, мы точно знаем, какие проверки есть в сборке.
Хорошая идея, но, вероятно, взорвется после того, как changeset-id достигнет 0xfffe, если вы ограничите его только одним из полей версии, major, minor, build, revision.
Мы используем управление версиями из Subversion и заставляем скрипты сборки обновлять информацию о версии сборки, поэтому контроль версий контролирует контроль версий.
Атрибут AssemblyVersionAttribute является частью удостоверения сборки. Это означает, что это другая сборка, и программы, связанные с этой сборкой, необходимо перекомпилировать / связать или применить политику версии. Мы не обнаружили такой апелляции, поэтому решили увеличивать AssemblyFileVersion только для каждого исправления и изменять AssemblyVersion только для каждого основного выпуска. Мы знаем, что это решение возвращает часть ада win32 dll. Мы увеличиваем AssemblyFileVersion для каждой сборки и маркируем / помечаем систему управления версиями этой версией, чтобы мы знали, из какого источника был получен двоичный файл.
Перекомпиляция или файл политики требуется только в том случае, если сборка имеет строгое имя.
На предыдущем задании, где мы использовали Subversion, я запускал сценарий nant для ccnet для извлечения версии репозитория и использовал это как окончательное число.
В этой работе мы используем VSS (шторку), поэтому на самом деле это не вариант, поэтому у нас есть политика обновления его вручную со следующими рекомендациями:
- Основные: значительные (> 25%) изменения или дополнения в функциональности или интерфейсе.
- Незначительные: небольшие изменения или дополнения в функциональности или интерфейсе.
- Сборка: мелкие изменения, ломающие интерфейс.
- Ревизия: исправления в сборке, не меняющие интерфейс.
Мы также синхронизируем версии сборки и файла. Версия сборки может быть легко прочитана программно, а версия файла может отображаться в виде столбца в режиме сведений в проводнике Windows.
Мы стараемся встраивать дату выпуска (или сборки) в сборку. Например, при сборке сегодня версия будет «2008.10.06» (сценарий сборки обновляет ее).
Звучит хорошо, но если вы делаете несколько сборок в день или поддерживаете несколько веток, я вижу, что это довольно быстро разваливается.
Совершенно верно. Включение номера сборки или времени сборки может быть жизнеспособным решением.
Вы также можете использовать время, см. stackoverflow.com/questions/971476/…
В моем текущем проекте мы используем номер версии Subversion как наименее значимую (сборочную) часть номера версии, и мы используем сценарий Nant для создания файла AssemblyInfo проекта. Мы используем один и тот же номер версии для атрибутов AssemblyVersion и AssemblyFileVersion. (Остальные три части - это major.minor.point, где major.minor будет увеличиваться каждый раз при изменении схемы базы данных, а точка увеличивается для каждого выпуска.)
Мы начали с того, что номер сборки просто увеличивали, но это требовало, чтобы файл версии регистрировался для каждой сборки, и вызывало конфликты при слиянии. Когда это оказалось невозможным, мы начали использовать CruiseControl.NET для генерации номера сборки, но это затруднило воспроизведение определенных сборок вручную. В итоге мы перешли на текущую схему (Subversion-revision).
Примечание. К сожалению, с .NET невозможно полностью воссоздать сборку из прошлой ревизии, потому что компиляторы .NET кодируют текущую метку времени в объектный файл при компиляции. Каждый раз, когда вы компилируете один и тот же код, вы получаете другой объектный файл.
С CruiseControl.NET у вас есть каждая отдельная сборка, когда-либо созданная, нет причин пересобирать старую версию. Если вы хотите добавить исправления в более старую версию, вам необходимо разветвить свой код в системе управления версиями для этой конкретной версии.
Есть разница между извлечением сборки из хранилища и возможностью доказать, что вы захватили все части, необходимые для сборки любого конкретного выпуска. Существует множество переменных среды, которые могут повлиять на создание любой конкретной сборки. Мой стандарт заключается в том, чтобы оформление заказа было как можно более автономным, чтобы вы могли выполнять оформление заказа на новой машине и создавать программное обеспечение с нуля. Этого труднее достичь с .Net (в отличие от Java), но все же это достойная цель. Это означает, что я зашел так далеко, что зарегистрировал Java, Ant и все библиотеки вместе с моим исходным кодом.
У нас есть наш сервер сборки CruiseControl.NET, который встраивает номер списка принудительных изменений в AssemblyFileVersion - это позволяет нам отслеживать исходный код для любой сборки, созданной сервером сборки. (Мы всегда строим из основной ветки.)
Для сборок, на которые будут ссылаться клиенты, мы оставляем константу AssemblyVersion, если нет критических изменений, и в этом случае мы увеличиваем версию, чтобы гарантировать, что код клиента будет перестроен для новой версии.
Я вижу здесь много сообщений об использовании номера версии Subversion в качестве компонента версии сборки. Осторожно: каждый из 4 номеров версий, доступных в Windows (a.b.c.d), ограничен 16 битами (макс. = 65535). Номер редакции подверсии может легко превысить этот предел, особенно если вы размещаете несколько проектов в одном репозитории.
Да, гораздо лучше использовать AssemblyInformationalVersion.
Ссылка на указанный атрибут: msdn.microsoft.com/en-us/library/…
Не могли бы вы рассказать, как это помогает? пытается ли он проанализировать его и только предупредить, а не потерпит неудачу, если он превышает? Это настоящая проблема / позор. Наличие svn revs в номере версии действительно удобно, но теперь у нас есть 70 000+ ревизий, поэтому он постоянно падает.
@JonH: если вы попытаетесь поместить такой номер версии в код C#, например как [assembly: AssemblyVersion("1.1.1.70000")] , компилятор остановится на ошибке Ошибка при отправке атрибута System.Reflection.AssemblyVersionAttribute - «Указанная версия 1.1.1.70000 недействительна».
Ага ... это то, что у меня / у нас есть прямо сейчас ... Я предполагаю, что это неразрешимо.
Какое поле номера версии?