Алекс Jenter - Программирование на Visual C++. Архив рассылки
- Название:Программирование на Visual C++. Архив рассылки
- Автор:
- Жанр:
- Издательство:неизвестно
- Год:неизвестен
- ISBN:нет данных
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Алекс Jenter - Программирование на Visual C++. Архив рассылки краткое содержание
РАССЫЛКА ЯВЛЯЕТСЯ ЧАСТЬЮ ПРОЕКТА RSDN, НА САЙТЕ КОТОРОГО ВСЕГДА МОЖНО НАЙТИ ВСЮ НЕОБХОДИМУЮ РАЗРАБОТЧИКУ ИНФОРМАЦИЮ, СТАТЬИ, ФОРУМЫ, РЕСУРСЫ, ПОЛНЫЙ АРХИВ ПРЕДЫДУЩИХ ВЫПУСКОВ РАССЫЛКИ И МНОГОЕ ДРУГОЕ.
Программирование на Visual C++. Архив рассылки - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
• Revision– Номер ревизии для текущего построения.
В версии выделяется основная часть и дополнительная. При поиске нужной сборки, основная часть версии должна строго совпадать, а с дополнительной частью всё происходит хитрее. Если будет найдено несколько сборок с одинаковыми основными частями, то будет выбрана сборка с наибольшей дополнительной частью. Версию сборки вы можете задать при помощи параметра командной строки либо при помощи атрибута System.Reflection.AssemblyVersionAttribute. Здесь, правда, есть одна хитрость: вы можете задавать версию не полностью, а только ее часть. К примеру вот так: "1.*","1.5.*,@1.5.2.*". При отсутствии каких либо частей, компилятор допишет их сам по следующим правилам:
• Minor– приравнивается к нулю
• Build– приравнивается количеству дней прошедших с первого января 2000 года
• Revision– приравнивается количеству секунд, прошедших с полуночи, деленных на два.
Такая, казалось бы, странная схемы выбрана далеко не случайно: она позволяет гарантировать уникальность версии для каждого построения приложения, что, вообщем-то, немаловажно.
Я долго думал, как на словах описать эту технологию, но что-то ничего не лезло в голову, поэтому я решил нарисовать. Думаю, что, посмотрев на рисунок, вы сразу многое поймёте. Главное, обратите внимание на версии.

Рис. 6
Идея состоит в том, что для одного и того же приложения могут быть загружены разные версии одной и той же сборки, и при этом оно ничего не будет знать об этом. Для примера, библиотеки, обозначенные на рисунке цифрами 1 и 2, будут загружены для нашего приложения и может даже будут одновременно работать, но ни одна из них не узнает о существовании другой, что позволит избежать каких-либо конфликтов.
ПРЕДУПРЕЖДЕНИЕ
Не все так хорошо, как могло показаться. Да, система CLR не допустит прямых конфликтов между сборками разных версий, но приложение-то по-прежнему исполняется прежде всего операционной системой, а не CLR. И надо обязательно учитывать тонкости ОС, чтобы избежать проблем. К примеру, мы создаем именований объект ядра с некоторым именем, пускай это будет проецируемый в память файл. Все вроде кажется нормально, но тут подгружается в память другая версия нашей же библиотеки, и создает проецируемый в память файл с таким же именем. И что? А то, что для него не создается новый файл, а открывается уже существующий, созданный ранее другой версией нашей библиотеки. Думаю, вы сами можете себе представить, что при этом может произойти. При проектировании ваших собственных сборок вы должны обязательно помнить о таких, казалось бы, незначительных вещах. Это позволит вам в будущем избежать множества неприятных проблем.
Допустим, что среда выполнения (CLR) при загрузке приложения нашла требуемую сборку с подходящей версией. По идее, надо начать ее загружать, но возникает вопрос: а как узнать, что это действительно именно та сборка, которая нам нужна, а не другая. Ведь возможно, что кто-то захочет выдать свою сборку за чужую, или нужная сборка оказалась поврежденной, скажем, при передачи по сети. COM, к примеру, не предусматривал решения этой проблемы. В .NET для решения данного вопроса используются односторонние хэш-функции, в простонародье называемые контрольными суммами. В дополнении к информации об используемой сборке, во время компиляции считается контрольная сумма используемой сборки и помещается вместе с информацией о версии. Во время загрузки проверяется контрольная сумма, и на основание этой проверки будет вынесет вердикт о валидности сборки. По умолчанию используется хэш-функция SHA1. Плюс еще используется технология подписывания (signing) сборок, основанная на открытых криптографических алгоритмах с парными ключами. Вообще, ребята из Microsoft здорово поработали над этой проблемой. Ими было применено очень много интересных решений, о которых я, возможно, расскажу в отдельной статье.
Для простого развертывания приложений были существенно расширены сервисы, предоставляемые Windows Installer. Теперь он полностью поддерживает .NET. Создание инсталляций станет более простым, так как теперь данная возможность интегрирована в стандартную поставку среды разработки .NET. То есть вы сможете использовать все современные сервисы, предоставляемые Windows Installer, в ваших приложениях, не прибегая к средствам сторонних производителей. А предоставляет он их, кстати, не мало, но об этом в отдельной статье.
Хотя вам может показаться, что все, что я рассказал, не особо нужно, но на самом деле это совсем не так. Вы, конечно, можете сказать: "Зачем мне знать какие-то страшные низкоуровневые подробности, когда можно заняться чем-нибудь конкретным, к примеру написать компонент для .NET". Я считаю, что такой подход крайне неверен. Изучая систему сверху, невозможно понять всей сути происходящего в ней, вы сможете лишь заучить некоторые стандартные приемы работы с системой, о которых вы где-либо прочитаете или найдете соответствующий пример. Если же понять систему изнутри, то она откроется для вас с совершенно новой стороны. Вы сможете решать проблемы совершенно неординарным способом, основываясь не на каких-то там примерах, а на фундаментальных знаниях о системе. То, что я осветил в статье, является лишь маленькой верхушкой огромного айсберга .NET. Впоследствии я буду описывать некоторые из технологий, упомянутых выше, более детально, но все равно обо всем написать я никак не смогу при всем своем желании. Прочитав статью, поэкспериментируйте, посмотрите, поизучайте то, что вас заинтересует. Главное – никогда не останавливайтесь на достигнутом.
Это все на сегодня. До скорого!
Алекс Jenter jenter@rsdn.ru Duisburg, 2001. Публикуемые в рассылке материалы принадлежат сайту RSDN.Программирование на Visual C++
Выпуск №61 от 27 января 2002 г.
Добрый день, дорогие друзья!
Сегодня я чрезвычайно рад сообщить вам отличную новость – появился новый совместный проект сайтов www.rsdn.ru, delphi.mastak.ruи www.optim.ru– профессиональный журнал для программистов RSDN Magazine.
Все его содержание создается профессиональными программистами, и рассчитано на профессиональных программистов. Мы считаем, что материалы журнала должны носить не обзорный, а углубленный характер и быть реально полезны программисту в его повседневной работе. Именно практическая полезность материалов является для нас важнейшим критерием формирования контента издания. Об уровне и характере статей вы можете судить по материалам наших сайтов.
Читать дальшеИнтервал:
Закладка: