Здравствуйте, уважаемые читатели.

Сегодня мы будем рассуждать о болезненном процессе - установке написанных нами vb приложений на компьютеры клиентов.

В принципе вопрос не стоит и выеденного яйца. Запустил Package & Deployment Wizard, сделал сетап... Но это только теоретически. В самом деле, все значительно сложенее чем кажется. Начиная с того, что в самом PD Wizard в оригинальной версии присутствовала ошибка, из за которой сетап приготовлнный на машине с росийским форматом даты не мог быть установлен . Ошибку исправили в третьем сервиспаке, для тех, кто почему то не ставит сервис паки, решение проблемы описано здесь
Однако и это еще не беда. Беда в другом. Виндоус NT и 9х устроена так, что System дирректория является настоящей помойкой. Т.е. там есть масса необходимых системе файлов - спору нет, но при этом кто угодно может прийти и переписать эти самые системные библиотеки. Например заменить их на старые версии.

Как результат, никто не может быть уверен, что принесенные сетапом библиотеки ( особенно если это общеупотребительные библиотеки) именно те, которые необходимы вашей программе. Здесь даже название этой проблеме придумали - Dll hell . Кстати, тем самым "возмутителем спокойствия" - сетапом с неправильно настроенными свойствами для системным библиотек может быть и ваш сетап.
Так что давайте разберемся с тем, как все это работает в принципе.

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

Как вы слышали, начиная с версии 5 VB умеет компилировать свои проекты в "настоящий" код. Это означает следующие действия:
Пользователь запускает exe файл, EXE загружается в память и выполняется, обращаясь к необходимым библиотекам.
Раньше, (и сейчас при желании) проект мог быть скомпилирован в PPP код, который работает чуть иначе, чем написано выше:
Пользователь запускает exe файл, EXE загружается в память и тянет за собой витруальную VB машину , далее под этой "средой" выполняется условно откомпилированный PPP код. Естественно, вызовы к сторонним библиотекам тоже могут иметь место. Этот вариант несколько медленнее в исполнении(скорость зависит от "изошренности" кода внутри), при этом сам exe занимает меньше места.

Главная ошибка тех, кто считает, что native compilation решает все проблемы, связанные с присутствием необходимых библиотек в том, что они путают процесс компиляции со статическим включением библиотек в тело exe .
Я процитирую здесь уместное высказывание одного из читателей конференции:

"Идея избавления от гигантомании dll" возникает _слишком_ часто. Разве не понятно, что:
1. Если Вы пишете без использования каких бы то ни было библиотек, то Вы будете писать очень неэффективно.
2. Если вы пишете с использованием каких бы то ни было библиотек, то их (библиотеки) придется включать в состав дистрибутива;
2.1. Если Вы будете включать в дистрибутив библиотеки "в чистом виде" (какими они были на вашем компьютере), то размер дистрибутива будет значителен;
2.2. Если Вы будете включать в дистрибутив "покусанные" библиотеки (только те фрагменты, которые Вы используете в данной программе), то вырастет суммарный объем Ваших приложений (реализация популярных функций будет во всех приложениях).
3. Есть еще вариант "тысячи миллиардов маленьких библиотек", при этом собираются вместе плюсы 2.1 (shared libraries) и 2.2 (в каждом дистрибутиве то и только то, что необходимо для работы программы), но я не слышал про реализацию этого варианта, наверное и в этом есть какие-то минусы.
Простая диалектика: без плохого не бывает хорошего (если бы было хорошее без плохого, все остальные варианты не жили бы). Вы выбираете критерий (что для вас хорошо в данный момент), и действуете согласно. Hигде я не употреблял слов Visual Basic, C и т.п.
Hе все языки поддерживают описанные возможности, выбирайте подходящий язык."
Александр Козлов.

У VB в зтом отношении нет особого выбора. Вы можете использовать библиотеки , или отказаться от части их них. Всяко придется иметь на машине клиента MSVBVM60.dll - это собственно, и есть виртуальная машина VB .
Вы вправе спросить - что же я плел про native compilation несколькими абзацами выше - поясняю. Да, сама виртуальная машина (как интерпретатор РРР кода) нам не нужна, но все остальное, что делает встроенный Бэйсик, это именно она - создание формы, стандартных контролов, использование встроенных фунций VB - все расположено там. Обойтись - не выйдет. Размер этого файла не маленький - 1.4 мб , и никуда от этого не денешся. Едиственная радость - Windows 2000. Windows ME, Windows 98 SE уже содержат эту библиотеку , и она есть сразу после инсталяции. Т.е. программа написанная без использования внешних библиотек будет работать там сразу - в виде "голого" exe.

К файлам, также необходимым для работы VB, относятся библиотеки автомэйшн ( ну не знаю как это переводить), все операции связанные с обьектами, вызовы методов эвентов и свойств, COM короче говоря, используют эти библиотеки. Точнее сам VB нуждается в них. Это:
Oleaut32.dll
Olepro32.dll
Stdole2.tlb
Asycfilt.dll
Comcat.dll

На 100% машин эти файлы уже установлены. Лeжат они в sysytem (system32 for NT) и проблема в том, что они могут быть устаревшие . При этом переписать их "ручками" не получится, так как некоторые из них используются системой . Программы, осуществляюшие сетап побеждают это дело хитростью - для 9x они копируют эти файлы во временный каталог и создают специальный bat файл, запускающийся при старте ( до поднятия GUI) Windows. Для NT существует специальный способ копирования заблокированных системой файлов (подробнее не расскажу, так как не знаю.) В реальной жизни "ручками" это никто не делает.

Пока мы рассуждали о программе(VB проекте), которая не ссылается на внешние библиотеки. Как определить ссылается или нет, и может чего лишнего подцеплено, ненужного? Просто посетите меню Project
Там вы найдете подменю "Сomponents" - в нем лежат доступные к использованию контролы. Пометьте чекбокс "Selected Items Only" Если лист пуст - вы не используете дополнительных контролов вообще, и полдела уже сделано. Если лист имеет записи,, то выделяя одну за другой вы можете посмотреть в какой библиотеке или ocx файле лежат контролы. Если вы не используете их - уберите галочку, не загромождайте сетап лишними файлами.
Похожим способом нужно поступить с меню Project - References . Тут возможностей просмотреть "только выбранное" нету, так что прийдется пройтись по всему листу. Как минимум 4 ссылки будут помечены. Это сам VB, его обьекты, Обьекты и процедуры и OLE Aвтомэйшн .
Если ссылок больше - стоит приглядеться к ним понимательнее - нужны ли они вам. Если не нужны , или вы неуверенны - не бойтесь пробуйте снять галочку. Если ссылка используемая, то применить изменения не выйдет.
Итак, мы с вами "почистили" сам проект. Если вам нужно распостранять что то несложное, то осваивать серьезный "изготовитель" сетапов никчему. Если же ваша программа - это коммерческий пакет или вы используете много разных "штучек" типа контролов сторонних производителей, ADO или еще что громоздкое, или в конце -концов желаете, чтобы сетап выглядел профессионально, то прямая дорога взять в руки Wise Instalation System ( свежая версия 8.*) или Install Shield Pro ( свежая версия 6.2). Обе эти программы обладают широкими возможностями по созданию сетапов, включая специальные компоненты, позволяющие отслеживать "внешние" обращения проекта, сетап которого изготавливается, к библотекам и документам.
Как и Пакадж визард эти программы лезут в исходный текст *.vbp и смотрят на строчки типа Reference, в которых описано какие же библиотеки надо подключать. к проекту, и соотвественно их нужно запаковать в сетап. После чего находится соотвествующий *.dep файл (Dependency file - лежат в System дирректории), содержащий информацию о том, что нужно положить в сетап еще, для нормальной работы этой компоненты. Однако, программа может содержать вызовы внешних exe (или документов), которые не описаны в референсах. Конечно вы можете добавить такие файлы в сетап "ручками", но можете и натравить на них дополнительные возможности указанных Install Makers. По поводу этих пакетов - Wise ближе к VB , я бы сказал "родственнее". Программисту, который никогда не писал на С - Install Shield покажется сложнее, и непонятнее. В самом деле у обоих систем есть свои плюсы и минусы.

Подвожу итоги разговора. Для создания сетапа надо
- почистить проект от лишних референсов и компонентов.
- позаботиться о том, что в сетп попало все, что вы реально используете.
- создать сетап , либо с помошью специальных пакетов , либо с помошью визарда.

Теперь еше один совет. Сетап , правильный setup, вам нужен единожды. Првый раз , после этого можно брать свой eхe на дискетку и раздавать юзерам. Если вы используете самодельные ocx или dll - то они требуют регистрации. зарегистрировать их руками можно используя regsvr32.exe имя_регистрируемого_файла. Регистрировать такие компоненты надо после любой компиляции. кстати, если вы используете компоненты, и меняете их - вероятнее всего придется перекомпилировать и exe проекта.

Уф-ф-ф, сегодня большой выпуск. Совсем даже и не хитрость, а как бы фундаментальные знания. Надо будет статью из этого сделать.
Уверен, что этот выпуск принесет мне немало головной боли - посыпятся вопросы типа "я вот тут сделал сетап , а он все равно не работает". Чаще всего ответ будет один:
Если приложение использует ADO или ODBC - не забывайте включить в сетап и выполнить mdac_typ.exe . В некторых случаях необходим предварительный сетап DCOM95 . Если вы создаете свои контролы на основе чужих - не забывайте включать файлы необходимые для них .
Проверяйте версии библиотек, которые используются на вашем компе и у клиента.
Нередко проблемы возникают из за компонентов, в результате ошибок клиент может использовать ваш старый компонент вместо свежего, и это порождает ошибки.
Используйте свежие сервиспаки. Берегитесь установленных у клиента IE5.5 , эксплорер очень тесно интегрируется с системой, и это очень похоже на некий внеплановый сервиспак к операционке.

Ну и в любом случае - удачи вам.

Традиционная рекомендация из серии "куда пойти учиться" - по мнению читателей (а читатели выражают свое мнение не только письмами, но и покупками, статистика которых вполне доступна) лучший печатный учебник по VB . Отзывы читателей об этой книге можно посмотреть у меня на сайте - здесь
Книга, весьма полезная для понимания работы с API. А учитывая ее смешную стоимость - 45 рублей.... Короче, рекомендую