Главная » C# » Использование номеров версий в Visual C# (Sharp)

0

Номера версий предоставляют способ управления возможностями и надежностью приложения. Концепция номера версии почти исчезла из рынка пакетного прраммного обеспечения. Возьмем, например, версии операционной системы коании Microsoft: Windows 95, Windows 98, Windows 2000, Windows XP, Windows Vista и т. д.

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

Понимание номеров версий

Скажем, вы хотите скачать программу с открытым исходным кодом Capivara (пррамма для управления и синхронизации файлов на языке Java). Вы заходите  на сайт  программы  и  видите,  что для  скачивания  доступна самая  последняя  версия с номером 0.8.2. Номер версии состоит из трех частей, которые имеют следующее значение.

•   Основной номер. В примере основной номер — 0. Если основной номер меньше единицы, то версия считается из разряда бета. Но часто бета-версия совсем не означает, что программой нельзя пользоваться. Изменение основного номера версии указывает существенные  изменения  в  функциональности  программы. То есть то, что работало в версии 1, может не работать в версии 2. Примером может служить серверный проект HTTPD Apache, где версии 1.x и 2.x являются двумя разными реализациями.

•   Дополнительный номер. В примере дополнительный номер равен 8. Этот  номер определяет незначительные функциональные изменения в программном обеспении. Изменение дополнительного номера версии (например, с 7 на 8) указывт новые возможности, но старая функциональность продолжает поддерживатя. Изменение дополнительного номера также может указывать исправление ошибок или заплатки.

•   Номер заплатки. В примере номер заплатки равен 2. Номер заплатки указывает версию программы с заплатой для исправления ошибок или других изменений. Изменения не включают новые возможности, и функциональность не меняется.

При скачивании программы с открытым исходным кодом обычно предоставляется выбор нескольких версий. Например, могут предлагаться версии 4.23 и 4.29 (бета). Так как большинство людей хочет все самое новое и последнее, то вы можете иытывать искушение скачать версию 4.29. Но я бы посоветовал вам скачать версию 4.29, т. к. бета есть бета, и кто знает, как она будет работать. А версия 4.23 считаея отлаженной, и поэтому вероятность неприятных сюрпризов от нее намного меньше, чем от версии 4.29.

При выпуске программного обеспечения с открытым исходным кодом разработчи часто используют следующую терминологию:

•   Stable (стабильная) — версия стойкая к сбоям, и ее можно применять для прышленных целей;

•   Unstable (нестабильная) — версию не следуют применять для промышленных целей, но она, скорее всего, работоспособная с некоторыми сбоями;

•   Nightly (ночная) — версия, работоспособность которой принимается  под сомние; может работать, а может, и нет. Зачем вообще нужны ночные версии? Они предназначаются исключительно для разработчиков, чтобы  можно было отсливать протекание разработки и контролировать ее определенные аспекты;

•   Alpha (альфа) — версия для демонстрации концепций, на основе которых будет разработано планируемое ПО. Но наличие обещанной возможности в альферсии далеко не всегда означает, что она будет реализована в поставляемой версии.

Управление версиями сборок

Номера версий сборок .NET отличаются от номеров версий для программ с открым исходным кодом. Далее приводится пример присвоения номера версии сборке

.NET:

[assembly: AssemblyVersion("1.1.0.0")] [assembly: AssemblyFileVersion("1.1.0.0") ]

Атрибуты AssemblyVersion И AssemblyFileVersion МОЖНО добавить В любое место в сборке или приложении. Если вы используете Visual С# Express,  то атрибуты, скорее всего, вставляются в файл AssemblyInfo.cs.

Номер версии состоит из четырех частей. Слева направо это основная версия, долнительная версия, номер сборки и модификация. Номер сборки может отражать номер суточной сборки, но он не является обязательным. Идентификатор модифации может быть произвольным числом, но  он тоже не является  обязательным. Для своих сборок я применяю О в качестве номера модификации, а номер сборки считаю номером заплатки.

В Visual С# Express имеется встроенный механизм, который автоматически обнояет номера сборки и модификации. Можно также воспользоваться утилитой для управления версиями или обновлять номера вручную. Утилиту gacutil можно пренять многократно с множественными версиями (рис. 12.9).

ПРИМЕЧАНИЕ

Дополнительную информацию по использованию инструментов для управления веиями см.  в  следующих  блогах:  http://weblogs.asp.net/bradleyb/archive/2005/l2/02/ 4321 SO.aspx и  http://www.biasecurities.eom/blogs/jim/archive/2003/10/08/166.aspx.

На рис. 12.9 сборка versionAssembly была добавлена в кэш GAC три раза под тря разными номерами версий: 1.0.0.0, 1.1.0.0 и 1.2.0.0. Это дает приложению или другой сборке опцию обращения к любой из трех версий одной и той же сборки.

Чтобы приложение или сборка могли использовать другую сборку, для них неоодимо создать ссылку на нее. При компиляции приложения или сборки в ней дается ссылка на конкретный номер версии сборки. Например, если указана ссылка на версию 1.1.0.0 сборки versionAssembly, то тогда будет исполнена версия 1.1.0.0 данной сборки.

Добавление в конфигурационный файл перенаправления на сборку

Скажем, что приложению или сборке требуется использовать новую версию сбои VersionAssembly. Чтобы дать приложению знать о новой версии сборки, неоодимо обновить конфигурационный файл приложения, который ссылается на стую версию. Обновление конфигурационного файла включает перенаправление на новую версию сборки. По существу, перенаправление дает приложению знать, что при запросе определенной версии сборки следует вместо нее загрузить новую веию. Далее приведен пример перенаправления версии:

<?xml version="1.0"?> cconfiguration>

<runtime>

<assemblyBinding

xmlns="urn:schemas-microsoft-corn:asm.vl">

<dependen tAs s embly>

<assemblyldentity name="VersioningAssembly"

publicKeyToken="bd42f9cb!2b40dlb" culture="neutral" />

<bindingRedirect oldVersion="1.1.0.0"

newVers ion="1.2.0.0"/>

</dependentAssembly>

</assemblyBinding>

</runtime>

</configuration>

Этот конфигурационный файл содержит XML-элемент assembiyBinding, определяий коллекцию сборок, с которыми мы будем иметь дело. Данная коллекция сборок вставлена В элемент dependentAssembly. Элемент dependentAssembly Содержит два дочерних элемента : assemblyldentity И bindingRedirect. Элемен т assemblyldentity используется для идентификации сборки, для которой будет осуществляться  перенравление ссылки, И содержит дочерний элемент dependentAssembly.

Элемент bindingRedirect содержит два атрибута: oldVersion И newVers ion. Атрут oldversion идентифицирует ссылку на старую версию сборки  в вызывающей сборке  или  приложении.  Если  обнаружена  ссылка  на старую  версию  сборки,  то с помощью атрибута newversion определяется новая версия сборки, которую нуо  вызвать вместо  старой.  В  примере  номер старой  версии—  1.1.0.0,  а новой —

1.2.0.0. В новом номере увеличен дополнительный номер, чтобы указать новую версию сборки. Но связывающему перенаправлению безразлично, ссылается ли атрибут newversion на новую или старую версию сборки. Идентификаторы версий, указываемые в атрибутах newversion и oldversion, являются лишь тем, чем они есть — идентификаторами.

Источник: Гросс  К. С# 2008:  Пер. с англ. — СПб.:  БХВ-Петербург, 2009. — 576 е.:  ил. — (Самоучитель)

По теме:

  • Комментарии