все что связано с моей работой

Файлы

В следующем шаге мы должны определить носители, на которых мы хотим распространять наш инсталлятор. В дни CD и DVD, мы ряд ли будем нуждаться в нескольких носителях, но такая возможность есть (если Вам необходимо использовать несколько носителей, Вы можете указать отдельные диски, используя Id тега Media, DiskPrompt может содержать любое текстовое описание различных носителей, которое позволяет пользователю определить, какой носитель нужно использовать, Windows Installer будет использовать это описание, когда запросит его):


    

Используя атрибут EmbedCab, мы можем указать, «встроить» архив (cabinet) с нашими файлами в пакет или оставить отдельно. Встраивание — обычное решение для окончательного пакета установки (приводящее к одному, единственному, автономному файлу для скачивания или отгрузки на носителях). Если ни Cabinet, ни EmbedCab не будут определены, то исходные файлы останутся нетронутыми: тогда они могут быть скопированы непосредственно на распространяемых носителях, вместе с установочным .msi файлом.

Мы подчеркнули во введении, что Windows Installer, перешел от более раннего программируемого подхода к декларативному. Мы описываем иерархическую структуру нашей исходной структуры папок, использующей вложенные структуры XML, предполагая, что установщик воссоздаст эту структуру во время установки на пользовательской машине. Windows Installer требует, чтобы начинали описание с самой верхней папки, корневой, для всей установки. Для которой мы укажем в идентификаторе TARGETDIR, и это будет наш корневой каталог, который содержит исходный файл cabinet-архив или дерево исходных файлов пакета установки, который имеет предопределенное имя: SourceDir. Это обеспечивает основную связь между тем, откуда установить и куда установить:

Внутри этой корневой папки мы продолжаем описывать нашу фактическую структуру. Согласно правилам, располагаем устанавливаемые файлы в заранее определенные места. Например, приложения должны быть установлены в\Program Files\Company\Product. Ярлыки меню “Пуск”, рабочего стола, пользовательские настройки, и т.д. — у всех у них есть их свои предопределенные папки. Для нашего удобства среда установщика предоставляет все предопределенные имена, что очень облегчает обращение к ним (и это также освобождает нас от проблем локализации, потому что у этих папок могли бы быть различные, локализованные имена в неанглийских версиях Windows). В нашем текущем примере мы будем использовать три из этих имен, ProgramFilesFolder, ProgramMenuFolder и DesktopFolder. Заметьте, что эти предопределенные имена “раскрываются” в полные пути: например DesktopFolder – на целевой машине преобразуется к виду C:\Documents и Settings\User\Desktop, тег Directory – это все, что требуется, чтобы обратиться к этой папке. В нашем примере мы должны определить каждый уровень отдельно:

 
        
          

Обратите внимание, что для каждого элемента (и это будет иметь место в течении всего использования WiX), мы должны обеспечить Id идентификатор. В большинстве случаев эти идентификаторы должны быть уникальными, потому что мы будем ссылаться на них по всему исходному файлу WiX, поэтому убедитесь, что вы продумали схему именования, которая позволяет легко соблюдать уникальность. В некоторых случаях (например, ProgramFilesFolder) можно использовать предопределенные имена. В других случаях, мы будем использовать имена свойств (примерно соответствует строковой переменной), как например INSTALLDIR. Позже мы вернемся к этому свойству еще раз.

Понятие компонентов и правил, управляющих их использованием, является, вероятно, самым важным понятием технологии Windows Installer и несоблюдение этих правил является основной причиной сбоя во время установки. Для нас очень важно хорошо понимать и разобраться в работе компонентов прежде, чем мы продолжим нашу первую сборку.

Компонент атомарная единица которая должна быть установлена. Он может содержать – файлы ресурсов, ключи реестра, ярлыки или что-нибудь еще, который должен всегда устанавливаться как единый блок. Установка компонента никогда не должна влиять на другие компоненты, удаление одного никогда не должно наносить ущерб другим компонентам или оставить все ресурсы на целевой машине. Как следствие компоненты не могут совместно использовать файлы: один и тот же файл, располагающийся в одном и том же месте, никогда не должен включаться больше чем в один компонент.

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

Опять же, компонент должен содержать только элементы, которые не могут функционировать друг без друга и они всегда должны быть установлены или удалены вместе. Из этого следует что, если каждый файл — самостоятельный, то ваши компоненты будут содержать по одному файлу каждый. Это не только нормально, но именно то, что вы должны делать. Не бойтесь, Windows Installer может эффективно обрабатывать тысячи компонентов и более, если это необходимо.

Итак, у нас есть компонент, состоящий из трех элементов: файла и двух ярлыков, указывающих на него. У компонента должен быть свой собственный идентификатор Id такой же уникальный GUID (компилятор WiX, и компоновщик предупредит Вас, если Вы, попытаетесь повторно использовать какой-нибудь GUID). Это очень важно — GUID-ы — это единственный механизм позволяющий Windows Installer-у различать компоненты.

Нарушение правил компонент, будет иметь тяжелые последствия: ресурсы могут быть не удалены во время удаления приложения, общий ресурс может быть ошибочно удален в то время как другое приложение по-прежнему нуждается в нем, переустановка приложения не восстановит функциональность, установка новой версии компонентов приложения может нарушить работу всего приложения.

 

Файл определен его именем. Кроме имени файла, Вы можете указать дополнительные атрибуты. Например, указывая атрибуту Vital значение no, Вы сообщаете инсталлятору что этот файл не важный. Обычно, при сбое во время установки файла по любой причине, установка всего приложения будет прервана, пользователю не разрешат проигнорировать проблему. Другие атрибуты, такие как ReadOnly, Hidden, System – устанавливают соответствующие файловые атрибуты.

Каждый компонент нуждается в хотя бы одном элементе с атрибутом KeyPath. Проверяя его Windows Installer, может определить, установлен ли компонент или нет. Хотя это не очень важно сейчас, когда мы только учимся устанавливать, но все равно важно определить такой KeyPath для каждого компонента, который используется чтобы поддержать функциональность удаления и восстановления в инсталляторе. Кроме того, компилятор будет жаловаться, если мы не определим его …

Ярлыки тоже имеют имена, а также другие важные элементы, как например рабочая папка и значок. Обратите внимание на разницу между Directory (папка куда ярлык будет помещен, такие как Меню "Пуск" или рабочий стол) и WorkingDirectory (место, куда ярлык указывает); WorkingDirectory не обязательный атрибут, если опущен, то он примет значение по умолчанию – папку, в которую будет установлен файл. Атрибут Icon определят Id значка, определенного где-то в другом месте, а не фактическое имя файла. Вы можете заметить, что мы снова использовали свойство INSTALLDIR, которую мы определили ранее, и указывающую куда мы устанавливаем, Program Files\Acme\Foobar 1.0. Описание других папок может быть сделано позже в исходном коде.

Атрибут Advertise указывает будет ли это обычный ярлык (простая ссылка, указывающая на файл в диалоге Свойства ярлыка) или «рекламируемый» (с ссылкой серым цветом, недоступной). Вторая форма позволяет Windows Installer восстанавливать установку, при замене или отсутствие файла на который указывает ярлык.


                
              
            

Тут описаны остальные два компонента нашего примера со своими уникальными Id и Guid:


              
            
            
              
                
              
            

Как Вы могли бы ожидать для приложения с сотнями или даже тысячами файлов, это будет означать сотни или тысячи компонентов. Да, это нормально. Не бойтесь, не будет никаких проблем с производительностью, Windows Installer лугко с этим справиться.

Ввод всех тех сотен или тысяч компонентов в исходный файл WiX представляет собой проблему, но другую конечно. У инструментария WiX есть маленькая утилита, которая может помочь с этим (но об этом позже), реальное решение – это концептуальное изменение. Перестаньте рассматривать программу установки как отдельное приложение, которое должно быть написано, когда основное приложение уже закончено. Поскольку исходные файлы WiX и сам инструментарий могут быть легко интегрированы в Вашу среду разработки, Вы должны разрабатывать их синхронно (имеется ввиду основное приложение и инсталляционный пакет). Как только Вы добавляете новый модуль или добавляете новую ссылку реестра в свою программу, измените одновременно соответствующий исходный файл WiX. Таким образом, инсталляционный пакет будет закончен вместе с приложением и не будет никакой необходимости выискивать файлы и другие сведения, требуемые для установки. Поскольку проект WiX может быть построен из модулей (об этом позже), то такой подход позволяет групповую разработку приложения.

И теперь, закрывающие тэги для элементов Directory — кроме самого первого, потому что мы еще не закончили. Оставаясь в первом, теге каталога TARGETDIR, мы определяем еще две папки, используя предопределенные имена WI: один для наших ярлыков в меню "Пуск" и для наших значков на рабочем столе. Только после этого надо будет закрывать первый тег Directory.

Поскольку при удалении продукта мы должны удалить папку программы, нам надо создать четвертый компонент. Тег RemoveFolder будет описывать наши действия при удалении. Атрибут On определит, когда папка должна будет удалена (возможные значения — install, uninstall и both). Как уже упоминалось, у всех компонентов должен быть свой собственный элемент с KeyPath. В данном случае это будет дополнительный тег RegistryValue. Этот тег выходит за рамки этого первого урока, мы возвратимся к этому позже. Помещение атрибута KeyPath в компоненте или папке будет работать, но это приведет к предупреждениям компоновщика. Так, что, пока примите это решение как есть, без объяснений, чтобы исключить любые сообщения от компилятора или компоновщика.

 
        
      

      
        
          
            
            
          
        
      
      
    

Обратите внимание, что мы указали идентификаторы Id, которые мы использовали при описании наших ярлыков в атрибуте Directory. Связав таким образом расположение ярлыка с физической папкой.

Наконец, мы говорим установщику, какие Feature (прим. перев. Features –возможности) мы бы хотели установить. «Feature» — это разделенные части нашего приложения, которое мы предлагаем пользователю, чтобы пользователь сам решил что установить, а что нет.” Feature” конечно будут зависеть от Вашего пакета программного обеспечения, но обычная схема выглядит так:

  • основные исполнимые программы, необходимые для функционирования программы;
  • документация, справочные файлы
  • учебные руководства, файлы примеров
  • связанные утилиты

В нашей первой установке у нас не будет таких «Feature». Во-первых, потому что мы вряд ли стоит разделять эти три файла. Во-вторых, чтобы это сделать, нам нужен пользовательский интерфейс, чтобы пользователь смог отмечать нужные ему части. Мы возвратимся к этому в следующем уроке, но пока, у нас будет одна Feature, главная. Мы должны перечислить наши компоненты используя из Id в нашей “части”:


      
      
      
      
    

Мы также должны добавить значок, который мы хотим использовать в ярлыке. Отметьте, что идентификатор Id должен иметь такое же расширение как и конечный файл, в нашем случае – это .exe:

 

Это сохранит исходный файл отдельно в заключительном пакете установки (так, что если Ваш исполняемый файл содержит и иконки, то в конечном пакете Вы будете иметь две копии файла). Если размер файла достаточно большой, то возможно имеет смысл сделать маленький .exe или .ico файл, содержащий только значки.


    ...
    

В заключение нам осталось только закрыть теги который остались открытыми:

  

Подведем итог: во-первых, мы обеспечили описание нашего приложения, и удобочитаемые тексты и необходимый GUID-ы. Во-вторых, мы определили носители, с которых мы хотим устанавливать. Затем, мы определили структуру папок наших файлов, куда они будут установлены. Эти файлы, вместе с их сопутствующими ресурсами, все вошли в соответствующие компоненты. И наконец, мы описали “ Feature ”, которые мы хотели бы предложить.

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

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.