WiX ծրագրային գործիքների համախումբ

Իրադարձություններ և գործողություններ

1. Պատվիրելի գործողություններ (custom action)

Windows համակարգում ծրագրային միջոցների տեղակայման ընթացքում, որոշ նեղ մասնագիտական գործողությունների իրականացման համար, որոնց համար Windows-ի տեղադրող ծրագիրը չի ապահովում որևիցե մի լուծում (օրինակ օգտագործողի գրանցման բանալու վավերցման իրականացում) , մենք կարող ենք օգտագործել այլ ճանապարհ՝ մենք կգրենք DLL, որի օգնությամբ մենք կստուգենք օգտագործողի գրանցման բանալու ճշտությունը:

Ստեղծենք մի պարզունակ DLL այդ նպատակի համար: Հետևյալ ելակետային կոդը կարող ենք ուղղակիորեն օգտագործել Visual C++-միջավայրում մեր ցանկալի DLL -ի ստեղծման համար՝

#include <windows.h>
#include <msi.h>
#include <msiquery.h>

#pragma comment(linker, “/EXPORT:CheckPID=_CheckPID@4″)

extern “C” UINT __stdcall CheckPID (MSIHANDLE hInstall)
{

char Pid[MAX_PATH];
DWORD PidLen = MAX_PATH;
MsiGetProperty (hInstall, “PIDKEY”, Pid, &PidLen);
MsiSetProperty (hInstall, “PIDACCEPTED”, Pid[0] == ‘1′ ? “1″ : “0″);
return ERROR_SUCCESS;

}

Նկատենք, որ այս DLL-ի անխափան կառուցման համար հարկավոր կլինի նախագծի հատկությունների  (Properties-> Linker-> Input-> Additional Dependences ) մեջ ավելացնել ՛msi.lib՛ կախվածությունը:

Ավելացնելով հետևյալ WIX կոդի հատվածը մեր հիմնական WIX տեղակայման ծրագրին, մենք դրանով իսկ կապահովենք DLL-ի  “CheckPID” ֆունկցիայի օգտագործումը օգտագործողի գրանցման բանալու վավերացումը իրականացնելու համար՝

<Condition Message=’This installation can only run in full UI mode.’>

<![CDATA[UILevel = 5]]>

</Condition>

<CustomAction Id=’CheckingPID’ BinaryKey=’CheckPID’ DllEntry=’CheckPID’ />
<CustomAction Id=’RefusePID’ Error=’Invalid key. Installation aborted.’ />

<InstallExecuteSequence>

<Custom Action=’CheckingPID’ After=’CostFinalize’ />
<Custom Action=’RefusePID’ After=’CheckingPID’>PIDACCEPTED = “0″ AND NOT Installed</Custom>

</InstallExecuteSequence>

<Binary Id=’CheckPID’ SourceFile=’CheckPID.dll’ />

Համառոտագրենք այս տարբերանիշերը (tag):

• նախ մենք Windows-ի տեղադրող ծրագրից պահանջում ենք, որ այն աշխատի օգտագործողի գրաֆիկական ինտերֆեյսի աշխատակարգով, որովհետև հակառակ դեպքում  օգտագործողը չի կարողանա մուտքագրել գրանցման բանալին: Դրան մենք հասնում ենք Condition տարբերանիշի օգնությամբ՝ <![CDATA[UILevel = 5]]>, նկատենք,  որ եթե երբևիցե ուզում ենք օգտագործել “=” ,  ”>” կամ “<” նշանները երկու մեծությունների համեմատության համար, ապա ստիպված կլինենք դրանք պարփակել “CDATA” պարույրիչով (wrapper)
• այնուհետև “CustomAction ” տարբերանիշի օգնությամբ նկարագրում ենք ‘CheckingPID’ պատվիրելի գործողությունը և “InstallExecuteSequence” տարբերանիշի օգնությամբ Windows-ի տեղադրող ծրագրին հայտնում ենք, որ ‘CheckingPID’ պատվիրելի գործողությունը պետք է ակտիվացվի ‘CostFinalize’  ստանդարտ գործողությունից հետո: ‘CheckingPID’ պատվիրելի գործողությունը  կկանչի ‘CheckPID’ DLL-ի   ‘CheckPID’ ֆունկցիան, որը ‘PIDACCEPTED’ հատկությանը կվերագրի 0 կամ 1, ըստ որի  էլ  կիրականացվի օգտագործողի գրանցման բանալու վավերցումը: Նկատենք, որ հատկությունների օգտագործումը ( մեծատառերով հայտարարված միայն, հակառակ դեպքում Windows տեղադրող գործիքը այն չի ճանաչի որպես ընդհանուր (public)  հատկություն ) միակ ճանապարհն է, արգումենտները պատվիրելի գործողություններին փոխանցելու և հետ ստանալու համար:
• ‘RefusePID‘ -ը մեր կողմից ստեղծված երկրորդ պատվիրելի գործողությունն է, որը նախատեսված է ակտիվացնել ‘CheckingPID’-ից հետո(After): Սա պայմանական  պատվիրելի գործողություն է, որը կգործարկվի միայն այն ժամանակ, եթե վերադարձված “PIDACCEPTED” հատկության արժեքը 0 է, այս դեպքում տեղակայման ընթացքում կերևակվի հաղորդագրություն սխալի մասին, ընդ որում, նկատենք նաև որ այս գործողությունը ակտիվանալու է միայն ծրագրի տեղակայման և ոչ թե նրա հեռացման ժամանակ:

SampleCA այս հղումը մեզ թույլ կտա բեռնավորել հենց այս նպատակով ստեղծված օրինակը և օգտագործելով փորձել այն զարգացնել:

2. Պատվիրելի գործողությունների ճկունացումը

Փորձենք օգտագործողի ինտերֆեյսը  փոխենք այնպես, որ եթե օգտագործողը պատահմամբ սխալ մուտքագրում կատարի գրանցման բանալու մուտքի ժամանակ, ապա հնարավորություն տանք նորից փորձելու:

Պատվիրելի գործողությունները օգտագործողի երկխոսության պատուհանից կարող ենք գործարկել օրինակի համար սեղմվող կոճակի օգնությամբ

<Control Id=”…” Type=”PushButton” …>

<Publish Event=”DoAction” Value=”CheckingPID”>1</Publish>

</Control>

“Publish” տարբերանիշի օգնությամբ Windows-ի տեղադրող ծրագրին հաղորդում ենք, որ “Next” կոճակը սեղմելիս պետք ե գործարկվի “CheckingPID” պատվիրելի գործողությունը: Հետևաբար անհրաժեշտություն չկա “InstallExecuteSequence” տարբերանիշով նախորոշել “CheckingPID” -ի գործարկման հերթականությունը: Բայց այնուամենայնիվ պատվիրելի գործողության հայտարարումը պարտադիր է:

<CustomAction Id=’CheckingPID’ BinaryKey=’CheckPID’ DllEntry=’CheckPID’ />

Օգտագործողին սխալի մասին տեղյակ պահելու նպատակով մեզ անհրաժեշտ կլինի կառուցել հաղորդագրության պատուհան՝

<Dialog Id=”InvalidPidDlg” Width=”260″ Height=”85″ Title=”[ProductName] Setup” NoMinimize=”yes”>
<Control Id=”Icon” Type=”Icon” X=”15″ Y=”15″ Width=”24″ Height=”24″
ToolTip=”Information icon” FixedSize=”yes” IconSize=”32″ Text=”Exclam.ico” />
<Control Id=”Return” Type=”PushButton” X=”100″ Y=”57″ Width=”56″ Height=”17″ Default=”yes” Cancel=”yes” Text=”&amp;Return”>
<Publish Event=”EndDialog” Value=”Return”>1</Publish>
</Control>
<Control Id=”Text” Type=”Text” X=”48″ Y=”15″ Width=”194″ Height=”30″ TabSkip=”no”>
<Text>
The user key you entered is invalid. Please, enter the key printed on the label
of the jewel case of the installation CD.
</Text>
</Control>
</Dialog>

Մեզ անհրաժեշտ կլինի նաև թարմացնել օգտագործողի ինֆորմացիոն էջը , որովհետև պատվիրելի գործողությունը կանչվելու է այս էջից՝

<Control Id=”Next” Type=”PushButton” X=”236″ Y=”243″ Width=”56″ Height=”17″
Default=”yes” Text=”[ButtonText_Next]“>
<Publish Event=”DoAction” Value=”CheckingPID”>1</Publish>
<Publish Event=”SpawnDialog” Value=”InvalidPidDlg”>PIDACCEPTED = “0″</Publish>
<Publish Event=”NewDialog” Value=”SetupTypeDlg”>PIDACCEPTED = “1″</Publish>
</Control>

Այժմ, երբ օգտագործողը սեղմի “Next” կոճակը , DLL -ի ‘CheckPID’ ֆունկցիան կկանչվի, և կախված նրանից թե ինչ կվերադարձնի ֆունկցիան, ըստ դրա էլ կամ կբացվի հաջորդ “SetupTypeDlg” պատուհանը (հաջող ավարտի դեպքում), կամ էլ կերևակվի սխալի մասին հաղորդագրությունը (անհաջող ավարտի դեպքում):

Չմոռանանք ավելացնել նաև՝

<Binary Id=”Exclam.ico” SourceFile=”Exclam.ico” />

տարբերանիշը (ծրագրի պատկերանշանի համար):

Այս պարբերությանը վերաբերվող օրինակի պարփակ տարբերակը կարելի է բեռնավորել այստեղից:

Նկատենք նաև, որ որպեսզի օգտագործողի գրանցման բանալին պատահաբար չմուտքագրենք Windows-ի տեղադրող ծրագրի լոգ (log) ֆայլում, մեր WIX կոդին ավելացնենք նաև հետևյալ տարբերանիշը՝

<Property Id=”PIDKEY” Hidden=’yes’ />

(Շարունակելի)

Այդ պահանջները կարող են նկարագրել անվանումների համակարգը, տվյալներին կամ այլ արտաքին պաշարներին դիմելու նմուշները և այլն: Կոդի ստուգման գործընթացի մեծ մասը իրենից ներկայացնում է մեխանիկական աշխատանք և կարող է ավտոմատացվել: Կոդի ստատիկ վերլուծության միջոցները դիտում են ծրագրային կամ միջանկյալ կոդը` փնտրելով մշակման որոշակի կանոններին բավարարելու փաստը:

Microsoft .NET Framework-ում ստատիկ վերլուծության այդպիսի միջոցներից մեկն է հանդիսանում FxCop-ը, անվճար միջոց` ստեղծված Microsoft-ի կողմից: FxCop-ը վերլուծում է .NET կոմպիլացված հավաքածուի (assembly) միջանկյալ կոդը և ներկայացնում է մշակման, անվտանգության և արդյունավետության բարձրացման առաջարկություններ: Ըստ լռության, FxCop-ը գնահատում է հավաքածուն հիմնվելով «Կլասերի գրադարանների մշակման նախագծային պահանջներով» սահմանված կանոնների վրա: Նախագծային հանձնարարականների կանոնները բաժանված են իննը մասի` ներառելով նախագծումը, համաշխարհայնացումը (globalization), արդյունավետությունը և անվտանգությունը: Կանոնի օրինակ է հանդիսանում «Իրադարձությունները չպետք է ունենան ‘before’ կամ ‘after’ պրեֆիքսներ»: Եթե FxCop-ը գտնում է BeforeUpdate իրադարձություն, նա խորհուրդ է տալիս փոխարինել այն Update-ով: Կարելի է նաև ընդգրկել կանոնների սեփական դաս, որը կարտացոլի ընկերության ներքին նախագծային հանձնարարականները:

Հավաքածուն վերլուծելու համար, աշխատացրեք FxCop-ը, ստեղծեքնոր նախագիծ (project) և ավելացրեք հավաքածքուն նախագծի մեջ. FxCop-ըկցուցադրի ավելի քան 200 կանոն, որոնք օգտագործվում են հավաքածուի վերլուծության ընթացքում: Նախագծում կարելի է անջատել գոյություն ունեցող կանոնները, կամ ավելացնել սեփական կանոններ: Սեղմեք ‘Analyze’ կոճակը վերլուծությունը սկսելու համար: Հավաքածուի տիպերի, կլասերի, մեթոդների ևանդամների դիտարկումից հետո, FxCop-ը արտապատկերում է վերլուծության արդյունքները, որոնցում թվարկված են կոդի հատվածներ և նրանցում խախտված կանոնները: Ընտրեք արդյունքներից մեկը` տեսնելու համար ավելի մանրամասն նկարագրությունը և առաջարկվող լուծումը:

FxCop-ը առաջարկվում է որպես առանձին կիրառական ծրագիր: Այն նույնպես ներառում է հրամանային տողի (command line) իրականացում, ինչը պարզեցնում է միացումը հավաքածուի ավտոմատացված գործընթացին: (FxCop-ին նման գործիք` Code Analysis-ը, տրամադրվում է Visual StudioTeam System-ի հետ միասին և ինտեգրացված է Visual Studio շապիկի մեջ:)

Microsoft-ի կողմից թողարկված կոդի ստատիկ վերլուծության այլ միջոց է հանդիսանում StyleCop-ը: Մինչ FxCop-ը գնահատում է միջանկյալ կոդի համապատասխանությունը նախագծային հանձնարարականներին, StyleCop-ը գնահատում է նախնական C# կոդի ոճը: Ոճի հանձնարարականները` դրանք նախնական կոդի ֆորմատավորման կանոններ են: Դրանք ցուցադրում են ‘for’ ցիկլերի, ‘if’ օպերատորների և այլ կառուցվածքների ֆորմատը և այլն: StyleCop-ի կանոնների օրանակ է հանդիսանում` ‘for’ օպերատորների մարմինը պետք է ներառված լինի ձևավոր փակագծերի մեջ, = և != օպերատորների երկու կողմը պետք է առկա լինենբացատի (space) նշաններ և այլն:

StyleCop-ը ինտեգրացված չէ Visual Studio Team System-ի հետ, նրանպետք է տեղադրել ինքնուրույն: Visual Studio-ից StyleCop-ի աշխատանքիժամանակ ծրագիրը վերլուծում է նախնական կոդը ընթացիկ որոշմանմեջ, արդյունքները արտապատկերելով որպեսնախազգուշացումներ (warning) սխալների ցուցակի պատուհատի մեջ: StyleCop-ը նույնպես կարող է ինտեգրացվել MSBuild համակարգի հետ: (solution)

Չնայած նրան, որ FxCop-ը և StyleCop-ը ցույց են տալիս կանոնների խախտումները, միևնունն է ծրագրավորողը պատասխանատու է այս միջոցների կողմից առաջարկների իրականացման համար: SubMain ընկերության CodeIt.Right միջոցը բարձրացնում է կոդի ստատիկ վերլուծությունը հաջորդմակարդակի` թույլ տալով ավտոմատ փոխակերպել կանոնների խախտումները նրանց համապատասխանող կոդի: Նման FxCop-ի, CodeIt.Right-ը համալրված է նախապես սահմանված կանոններով և թույլ էտալիս ավելացնել նոր կանոններ: Բայց CodeIt.Right-ում ավելի հարմար էնման կանոնների ստեղծումն ու օգտագործումը:

Օգտագործողների կողմից մշակված կանոնների օգտագործումը FxCop-ում պահանջում է կանոնների դասի ստեղծում և կոմպիլյացիա, որիցհետո` միացում FxCop-ին: CodeIt.Right-ում նման կանոնները ստեղծվում են օգտագործողի գրաֆիկական ինտերֆեյսի օգնությամբ. նոր կանոնի սահմանումը իրենից ներկայացնում է վարքի բազային նմուշի ընտրություն և նրա որոշ հատկությունների փոփոխություն: CodeIt.Right-ը ինտեգրվում է Visual Studio 2003/2005/2008 հետ, ինչպես նաև առաջարկում է հրամանային տողի իրականացում:

CodeIt.Right-ը Visual Studio-ից օգտագործելու համար, CodeIt.Right-ի մենյուից ընտրեք Start Analysis: Կոդի վերլուծությունից հետո, CodeIt.Right-ը արդյունքները ցույց է տալիս Visual Studio IDE-ի պատուհանի մեջ` թվարկելով յուրաքանչյուր կանոնի խախտումը: Այդ հաշվետվությունը կարելի է ձևափոխել XML-ի կամ MS Office Excel ֆայլ-ի:

CodeIt.Right-ի ամենամեծ առավելությունն է կոդի ավտոմատ մշակումը: Արդյունքների պատուհանում կարելի է ընտրել խախտումները, որոնց անհրաժեշտ է շտկել, որից հետո սեղմել Correct Checked կոճակը: CodeIt.Right-ի կողմից կատարված բոլոր փոփոխությունները նշվում են VisualStudio-ի կողմից և ավտոմատ փոփոխությունները կարելի է չեղյալ հայտարարել համապատասխան կոճակը սեղմելով:

Կոդի ստատիկ վերլուծության միջոցները տրամադրում են նախապես սահմանված նախագծային և ոճային հանձնարարականներին համապատասխանեցման` ապահովելու արագ և ավտոմատացված եղանակ: Նման հանձնարարականներին հետևումը թույլ է տալիս արտադրել ավելի միատեսակ կոդ, ինչպես նաև թույլ է տալիս բացահայտել անվտանգության, արդյունավետության, փոխազդեցություն և համաշխարհայնացման տարբերհնարավոր թերությունները: Կոդի ստատիկ վերլուծության միջոցները չեն հանդիսանում մարդու կողմից ստուգման փոխարինող միջոցներ: Դրա փոխարեն նրանք ստեղծում են կոդի նախնական ակնարկ և բացահայտում են այն տիրույթները, որոնք պահանջում են ավելի շատ ուշադրություն ավագ մշակողի կողմից:

Աղբյուր. http://msdn.microsoft.com/ru-ru/magazine/dd263071.aspx

WiX ծրագրային գործիքների համախումբ

Իրադարձություններ և գործողություններ

1.Ներածություն

 Նախորդ անգամ մենք տեսանք թե ինչպես կարելի է ստեղծել լրիվ կարգաբերելի(ճշգրտելու հնարավորությամբ), Windows տեղակայվող փաթեթներ:  Տեղակայման հետ կապված խնդիրների մեծամասնությունը կարող է լուծվել մեր ձեռք բերած գիտելիքների շնորհիվ: Բայց միշտ լինում են խնդիրներ, երբ պահանջվում է մի փոքր ավելին, քան թույյ են տալիս ստանդարտ հնարավորությունները:  Windows տեղակայող ծրագիրը տեղակայման ընթացքում իրագործում է բազմաթիվ քայլեր, որոնք մենք կանվանենք տեղակայման գործողություններ:  Այդ գործողություններից ամենահիմնականները և նրանց հարող տարրերը ցուցակագրվում են ավտոմատ կերպով, այլ կերպ ասած  նրանց հերթականությունը կանխորոշվում է WiX ծրագրային փաթեթի օգնությամբ՝ տեղակայվող տվյալների բազայի ստեղծման ժամանակ: 

2. Տեղակայման ստանդարտ գործողություններ

Ընդհանուր դեպքում նրանք իրենցից ներկայացնում են գործողությունների հետևյալ շարքը՝

AppSearch

• LaunchConditions
• ValidateProductID
• CostInitialize
• FileCost
• CostFinalize
• InstallValidate
• InstallInitialize
• ProcessComponents
• UnpublishFeatures
• RemoveShortcuts
• RemoveFiles
• InstallFiles
• CreateShortcuts
• RegisterUser
• RegisterProduct
• PublishFeatures
• PublishProduct
• InstallFinalize
• RemoveExistingProducts

Գործողությունների իրական հերթականությունը մենք կարող ենք իմանալ օգտագործելով Orca MSI խմբագրիչը տվյալ տեղակայվող փաթեթի համար: Մեր դեպքում այն կունենա հետևյալ տեսքը՝

 Այս իրադարձությունների հերթականությունը կարող ենք վերադասավորել օգտագործելով համապատասխան խումբը՝

• AdminUISequence
• InstallUISequence
• AdminExecuteSequence
• InstallExecuteSequence

Ադմինիստրատիվ տիպի տեղակայման կարելի է հասնել msiexec /a հրամանի օգնությամբ: Տեղակայման այս տիպը տեղակայվող փաթեթի համար ցանցում ստեղծում է «սկզբնաղբյուր կերպար», դրանով իսկ Windows աշխատախմբի անդամների համար հնարավորություն ստեղծելով օգտագործելու այս ակունքը բնօրինակ տեղակայվող փաթեթի փոխարեն (այս ֆունկցիոնալությունը տրվում է ազատ օգտագործման համար): Մեր մշակած բոլոր տեղակայվող փաթեթները կարելի է փորձել տեղակայել այս ճանապարհով:

Այսպիսով՝

• InstallExecuteSequence – Windows տեղակայող ծրագիրը գտնվում է մշտական բանակցության մեջ այս գործողությունների ցուցակի հետ՝ որոշելու համար նրանց հերթականությունը,
• InstallUISequence - կարևորվում է միայն այն ժամանակ, երբ տեղակայումը կատարվում է ՕԻ առկայությամբ(սա մեկ այլ ֆունկցիոնալություն է, որ կարելի է փորձել՝ msiexec – ը աշխատեցնելով /qn, /qb and /qr բանալիներով)

Տեղակայման գործողությունների հաջորդականությունը կարելի է փոխել օրինակի համար հետյալ կերպ՝

<InstallExecuteSequence>
<LaunchConditions After=’AppSearch’ />
<RemoveExistingProducts After=’InstallFinalize’>
</InstallExecuteSequence>

Սրանով մենք Windows տեղակայող ծրագրին հասկացնում ենք, որ  LaunchConditions գործողությունը պետք է կատարվի AppSearch գործողությունից հետո(After), իսկ RemoveExistingProducts – ը InstallFinalize–ից հետո:

Օգտագործելով՝

• Before - առաջ
• After – հետո

ատրիբուտները մենք կկարողանանք փոխել տեղակայման գործողությունների հերթականությունը: Իսկ  «Suppress = yes» - ով՝ կհաղորդենք, որ տվյալ գործողությունը տեղակայման ընթացքում չպետք է կատարվի:

3. Տեղակայման հավելյալ ստանդարտ գործողություններ

Կան շատ այլ հնարավոր ստանդարտ գործողություններ, որոնք ըստ լռության հերթագրված չեն տեղակայման գործողությունների ցուցակում: Օրինակ ScheduleReboot-ը տեղադրումից հետո օգտագործողից պահանջելու է վերագործարկել Windows – ը՝

CustomAction Id=’LaunchFile’ FileKey=’SimpleSampleAppexe‘ ExeCommand=” Return=’asyncNoWait’ />

տարբերանիշը (tag-ը) Windows տեղակայող ծրագրին կհաղորդի, որ SimpleSampleAppexe որոշիչով  աշխատածրագիրը պետք է գործարկվի ասինխրոն (անհամաժամ) կերպով: Եթե «պատվիրվող» գործողությունը պայմանական է, ապա մենք հնարավորություն ունենք պայմանը իրականացնել օգտագործելով Custom տարբերանիշ`

<Custom Action=’LaunchFile’ After=’InstallFinalize’>NOT Installed</Custom>

Սրանով մենք Windows տեղակայող ծրագրին հաղորդում ենք, որ տեղակայման ընթացքում ծրագիրը պետք է գործարկվի միայն տեղակայման ժամանակ, և ոչ թե հեռացման: 

Որոշ դեպքերում, մենք կարող է ցանկանանք գործարկել տեղակայվող փաթեթում գտնվող ինչ որ ծրագիր՝ առանց նպատակային մեքենայի վրա տեղակայելու: Նման դեպքերում մենք կարող ենք FileKey ատրիբուտի փոխարեն օգտագործել BinaryKey ատրիբուտը՝

<CustomAction Id=’LaunchFile’ BinaryKey =’SimpleSampleAppexe‘ ExeCommand=” Return=’asyncNoWait’ />

Մենք կարող ենք նաև օգտագործել ցանկացած այլ ծրագիր, որը գտնվում է նպատակային մեքենայի վրա՝

<Property Id=’NOTEPAD’>Notepad.exe</Property>
<CustomAction Id=’LaunchFile’ Property=’NOTEPAD’ ExeCommand=’[SourceDir]Readme.txt’ Return=’asyncNoWait’ />

Պատվիրված գործողությունների ժամանակ կարելի է նաև նշել, թե ինչպես պետք է մշակվի գործարկման արդյունքը(վերադարձված արժեքը) օգտագործելով Return ատրիբուտը: Return ատրիբուտի հնարավոր արժեքներն են՝

• check - Windows տեղակայող ծրագիրը կսպասի գործարկվող ծրագրի ավարտին և կստուգի նրա կատարման արդյունքը,
• Ignore - Windows տեղակայող ծրագիրը կսպասի գործարկվող ծրագրի ավարտին, բայց կանտեսի նրա կատարման արդյունքը,
• asyncWait - Windows տեղակայող ծրագիրը նշված ծրագիրը կգործարկի ասինխրոն(անհամաժամ) կերպով, կսպասի գործարկվող ծրագրի ավարտին, և կստուգի նրա կատարման արդյունքը,
• asyncNoWait - Windows տեղակայող ծրագիրը նշված ծրագիրը կգործարկի սինխրոն(համաժամ) կերպով, այնուհետև թողնելով նրան ինքնուրույն:

Որևէ սխալի առկայության դեպքում հնարավորություն ունենք օգտագործողին տեղյակ պահել այդ սխալի մասին՝

<CustomAction Id=’AbortError’ Error=’Cannot solve this riddle. Giving up.’ />

Մի հատկության(property) արժեքը մեկ այլ նմանատիպ հատկությանը վերագրելու ուղիղ ճանապարհ չկա, բայց օգտագործելով CustomAction տարբերանիշը, մենք կարող ենք փակել այդ բացը՝

<CustomAction Id=’PropertyAssign’ Property=’PathProperty’ Value=’[INSTALLDIR][FilenameProperty].[ExtensionProperty]‘ />

Նկատենք, որ ֆայլապանակների ճանապարհները միշտ վերջանում են պարփակիչ նշանով՝ «/», ուստի կարիք չկա առանձնապես հոգ տանել նրանց համար ֆայլապանակների ճանապարհների կառուցման ժամանակ:

Դիրեկտորիան(directory) կարող է վերագրվել մեկ այլ նմանատիպ ներկայացման՝

<CustomAction Id=’PropertyAssign’ Directory=’INSTALLDIR’ Value=’[TARGETDIR]\Program Files\MyCompany\SimpleSampleAppexe 1.0\bin’ />

(Շարունակելի)

 WiX ծրագրային գործիքների համախումբ

Օգտագործողի ինտերֆեյս ( ՕԻ )

Նախաբան

Նախորդ անգամ մենք իմացանք թե ինչպե՞ս կարելի է նկարագրել այն տարրերը, որոնք մենք ուզում ենք տեղադրել նպատակային համակարգչի վրա: Թեև տեղակայման ընթացքում մենք տեսանք որոշակի ավտոմատացված պարզ տրամաբանություն, այնուամենայնիվ օգտագործողը հնարավորություն չուներ ակտիվորեն ներգործելու տեղակայման ընթացքի վրա:  Այսպիսով մեր ուսումնասիրության հերթական թեման կլինի՝ տեղակայման ընթացքի վրա օգտագործողի ակտիվ ներգործելու հնարավորությունները:

Windows Installer տեղակայման ծրագիրը չունի օգտագործողի հետ առնչման սեփական ինտերֆեյս (բացառությամբ մի քանի հաղորդագրության պատուհանների, որոնք օգտագործողին տեղեկացնում են տարբեր սխալների մասին և տեղակայման ընթացքը ցույց տվող պարզագույն պատուհանի): Տեղադրվող փաթեթները պետք է սահմանեն սեփական օգտագործողի ինտերֆեյս,  կոմպիլացնել և ընդգրկել այն սեփական .msi ֆայլի մեջ: Չնայած այն բանին, որ դրանից տեղակայվող փաթեթը որոշ չափով ծավալուն է դառնում (օգտագործողի տիպիկ ինտերֆեյսը սկսվում է մոտ 300կբ -ից, թեև նրա չափը կախված է նաև պատկերանշաններից և այլ գրաֆիկական տարրերից), այնուամենայնիվ  այն հնարավոր է դարձնում ակտիվորեն ներգործել տեղակայման ընթացքի վռա:

Բավականին դժվար կլիներ մեր համար, եթե օգտագործողի ինտերֆեյսը ստեղծելու լինեինք ինքներս՝ սկզբից: Բարեբախտաբար մենք դրա կարիքը չունենք: WiX ծրագրային գործիքների համախումբը ունի օգտագործողի ստանդարտ ինտերֆեյսների գրադարան, որի հիմքում ընկած են նախապես ստեղծված MSI - SDK ինտերֆեյսները, և որոնք ազատորեն կարելի բեռնավորել:  Գրադարանն ապահովում է օգտագործողի ամբողջական ինտերֆեյս տեղադրվող ծրագրային փաթեթների համար՝ ներառնելով այնպիսի ստանդարտ ինտերֆեյսներ, ինչպիսիք են՝ 

• Արտոնագրի համաձայնագիր,
• Պատվիրատուի մասին ինֆորմացիա,
• Տիպիկ / Ճշգրտմամբ / Ամբողջական տեղադրում,
• Տեղակայման նպատակային ֆայլապանակի ընտրություն,
• Պնակային պահանջների հաշվարկ,
• Ձևափոխել / Վերանորոգել / Հեռացնել և Հետընթացք

Oգտագործողի ինտերֆեյս պատուհանների տեսակներ

 «WixUIExtension.dll» գրադարանը (մտնում է WiX ծրագրային գործիքների համախմբի մեջ) ներկայացնում է հինգ տեսակի Oգտագործողի ինտերֆեյս պատուհաններ՝

• WixUI_Mondo – ապահովում է ամբողջական ՕԻ – Ողջույնի պատուհան, Արտոնագրի համաձայնագրի պատուհան, Տեղադրման տեսակի (տիպիկ , ճշգրտմամբ և ամբողջական) ընտրության պատուհան, Պնակի ծավալի արժեքավորման ևնպատակային ֆայլապանակի ընտրության պատուհան: Մենք կօգտագործենք ՕԻ այս տեսակը, երբ մեր արտադրանքիորոշ հատկանիշներ պետք չի լինի տեղակայել լռելյայն, այսինքն տիպիկ Տեղադրման տեսակի և ամբողջական Տեղադրման տեսակի միջև կա բովանդակալից տարբերություն:
• WixUI_FeatureTree - նման է WixUI_Mondo – ին, բայց Տեղադրման տեսակի ընտրության հնարավորություն չի ընձեռնում: ՕԻ – ի այս տեսակը միշտ ենթադրում է Տեղադրում ճշգրտմամբ և Արտոնագրի համաձայնագրի պատուհանից հետո առանց Տեղադրման տեսակի ընտրության երևակվում տեղակայվող մեծությունների ճշգրտման պատուհանը:
• WixUI_InstallDir – օգտագործողին թույլ է տալիս կատարել նպատակային ֆայլապանակի ընտրություն, առանց այլ հատկանիշների փոփոխման հնարավորության: Նպատակային ֆայլապանակի ընտրությունից անմիջապես հետո սկսվում է ավտոմատ տեղակայումը: Այս ՕԻ–ը հարմար է օգտագործել երբ ծրագիրը տեղակայման ընթացքում փոփոխման ենթակա լրացուցիչ հատկություններ չունի:
• WixUI_Minimal – ներկայացնում է պարզագույն ՕԻ միակ առնչման պատուհանով, որտեղ համատեղված են Ողջույնի և Արտոնագրի համաձայնագրի պատուհանները: Որից հետո անմիջապես սկսվում է ավտոմատ տեղակայումը: Այս ՕԻ – ը հարմար է օգտագործել երբ ծրագիրը տեղակայման ընթացքում փոփոխման ենթակա լրացուցիչ հատկություններ չունի ևնպատակային ֆայլապանակի ընտրության կարիք չկա:
• WixUI_Advanced շատ նման է WixUI_Minimal -ին, այն առաջարկում է պարզ, միակտտոց տեղադրում, միաժամանակ օգտագործողին հնարավորություն տալով փոփոխել որոշակի հատկություններ և ֆայլապանակներ, եթե նա ցանկանում է դա անել:

Oգտագործողի ինտերֆեյս պատուհանների օգտագործումը

 Որպեսզի ակտիվացնենք օրինակի համար՝ WixUI_Mondo օգտագործողի ինտերֆեյսը , մենք ընդամենը ստիպված կլինենք ավելացնել երկու տող՝

<UIRef Id=”WixUI_Mondo” />

<UIRef Id=”WixUI_ErrorProgressText” />

և իհարկե, VS-ի տեղակայման նախագծի վրա մկնիկի աջ կտտոցից բացված կոնտեքստային ցանկից ընտրելով “Add reference” հրահանգը, բացված պատուհանի օգնությամբ նախագծին տեղեկացնում ենք «WixUIExtension.dll» գրադարանի մասին (ավելացնելով նրա հղումը):

<UIRef Id=”WixUI_Mondo” /> հղումը WiX համակարգին տեղեկացնում է, որ օգտագործվելու է WixUI_Mondo տիպի ՕԻ – ը: Առանց երկրորդ հղման տեղակայվող փաթեթը ավելի փոքր կլինի, կօգտագործվեն սեղմ հաղորդագրություններ:

Այս երկու հղումները ամբողջականացնելու համար մեզ անհրաժեշտ կլինի ավելացնել ևս մեկ տող՝

 <Property Id="WIXUI_INSTALLDIR" Value="TOP_LEVEL_DIR" />

Այսպիսով մեր նախորդ օրինակին ավելացնելով այս երեք նոր տողերը մենք դրանով իսկ ապահոված կլինենք ամբողջական ՕԻ:

WiX նախագծի վրա մկնիկի աջ կտտոցից բացված կոնտեքստային ցանկից ընտրում ենք Build կամ Rebuild: Նախագծի կառուցումը պետք է որ ընթանա առանց սխալների ևWiX նախագծի ելքում կունենանք SimpleSampleWix.msi Windows տեղակայվող տվյալների բազան: Այն կարելի է գործարկել նպատակային համակարգչի վրա:

Ելնելով մեր խնդրի առանձնահատկություններից, մենք կարող ենք ճշգրտել որոշ տեսողական կամ այլ տվյալներ պարզապես փոխարինելով դրանք նորերով՝

  <WixVariable Id="WixUILicenseRtf" Value="path\License.rtf" />

  <WixVariable Id="WixUIBannerBmp" Value="path\banner.bmp" />

  <WixVariable Id="WixUIDialogBmp" Value="path\dialog.bmp" />

  <WixVariable Id="WixUIExclamationIco" Value="path\exclamation.ico" />

  <WixVariable Id="WixUIInfoIco" Value="path\information.ico" />

  <WixVariable Id="WixUINewIco" Value="path\new.ico" />

  <WixVariable Id="WixUIUpIco" Value="path\up.ico" />

• WixUILicenseRtf – նախընտրելի է ստեղծել պարզագույն խմբագրիչով (օրինակ Wordpad),
• WixUIBannerBmp (չափը՝ 500×63 պիկսել) - այս նկարը երևալու է բոլոր պատուհանների վերևի մասում՝ բացի առաջին պատուհանից,
• WixUIDialogBmp (չափը՝ 500×314 պիկսել) - այս նկարը երևալու է առաջին էջում,
• WixUIExclamationIco - Բացականչական նշանի պատկերանշաննը,
• WixUIInfoIco – ինֆորմացիոն նշանի պատկերանշաննը,
• WixUINewIco – Նոր ֆայլապանակի պատկերանշաննը,
• WixUIUpIco – ծնող ֆայլապանակի պատկերանշաննը

(Շարունակելի)

Մեկնարկային (.wxs) ֆայլից վերջնական՝ Windows տեղակայվող ֆայլ (.msi) ստանալու պարզագույն սխեմա

Պարզագույն քայլեր
1.Ընդհանուր հայացք

Ինչպես արդեն նշեցինք WiX ծրագրային գործիքների համախումբը թույլ է տալիս մեկնարկային (.wxs) ֆայլերից ստանալ տեղակայվող բազաներ (.msi տիպի ֆայլեր):

Ֆայլերի այսպիսի ձևափոխության կարելի է հասնել հետևյալ հրամանների օգնությամբ (ենթադրվում է որ Sample.wxs-ը մեկնարկային ֆայլ է)

• candle.exe Sample.wxs - նախագործարկում և կոմպիլացնում է WiX մեկնարկային ֆայլերը, արդյունքում ստանալով միջանկյալ օբյեկտային (Sample.wixobj)ֆայլեր
• light.exe Sample.wixobj – միջանկյալ օբյեկտային (.wixobj)ֆայլերը ձևափոխում է վերջնական Windows տեղակայվող ֆայլերի (Sample.msi)

Այս երկու գործիքները սկզբունքորեն նման են մեզ շատ ծանոթ կոմպիլյատոր և կազմավորիչ զույգին: Դեռ ավելին՝ light գործիքը կատարում է նաև ավարտված տեղակայվող տվյալների բազայի (.msi) ստուգում՝ փորձելով հայտնաբերել հնարավոր բացթողումներ և պրոբլեմներ:

Մեր օրերում, ինչպես սովորաբար, մենք սահմանափակված չենք միայն հրամանային տողով; Microsoft Visual Studio-ի և SharpDevelop-ի նման միջոցները թույլ են տալիս ստեղծել WiX-ի հետ ինտեգրացված միջավայր: Այս դեպքում մենք կարող ենք VS ընդհանուր լուծման մեջ ստեղծել WiX տիպի նախագիծ և ծրագրավորման միջավայրից չկտրվելով կառուցել վերջնական տեղակայվող փաթեթներ:

WiX ծրագրային գործիքների օգնությամբ ստացվող .msi ֆայլերը տեղակայող (կատարվող) ծրագրեր չեն, այլ զուտ տվյալների տեղակայվող փաթեթներ: Նրանք պարունակում են տեղեկություններ՝ թե ինչ ենք մենք սպասում Windows Installer-ից, որ կատարի տեղակայման ընթացքում, ինչպես նաև օգտագործողի հետ առնչվելու ինտերֆեյսը: Իսկ թե ինչպե՞ս տեղակայել աշխատածրագրերն ու այլ ֆայլեր, ինչպե՞ս ձևափոխել կամ գրառում կատարել Windows-ի ռեգիստրում և այլնի մասին ծրագրային տրամաբանությունը պարունակվում է Windows Installer-ի մեջ:

Այս ամենը խոսում է այն մասին, որ WiX մեկնարկային (ելակետային .wxs) ֆայլերը չեն կառուցվում մեր սովորական ծրագրերի նման: Մեր կողմից գրված WiX ծրագրում հրամանների հաջորդական կատարման մասին խոսք անգամ չի կարող լինել: Չի կարելի կարծել, որ WiX-ի ելակետային ծրագրի տեքստի տողերի հրամանները կատարվում են՝ հաջորդելով մեկը մյուսին: WiX-ի մասին պետք է մտածել որպես ֆունկցիոնալ , նկարագրական լեզու, ոչ թե որպես սովորական ծրագրավորման լեզու:

Առավել ֆիզիկական առումով ասած, WiX-ը իրենից ներկայացնում է Windows Installer-ի փաթեթող (wrapper-թաղանթ) , որի հնարավորություններն ու սահմանափակումները թելադրվում են նրա հիմքում ընկած Windows Installer-ի հնարավորություններով:

2.Մեր առաջին WiX նախագիծը

Մեր առաջին WiX տեղակայվող օրինակը պարունակելու է քիչ թվով տեղակայվող մեծություններ: Այն բաղկացած է լինելու՝

• մեկ .exe երևակայական աշխատածրագրից,
• մեկ .dll գրադարանից,
• մեկ օգտագործողի ձեռնարկից

և որի համար մենք կկատարենք հետևյալ քայլերը՝

* WiX միջավայրի տեղակայումը օգտագործողի համակարգչում

• որպես նախապայման WiX-ի տեղակայումը պահանջում է ProjectAggregator.msi–ի տեղակայում օգտագործողի համակարգչում
• այնուհետև տեղակայում ենք WiX-ը ինքը

* Նախագծի ստեղծումը

• MS VS –ի միջավայրում սովորական (File - New - Solution) եղանակով ստեղծում ենք նոր դատարկ լուծում և նրա մեջ ստեղծում ենք երեք նոր նախագծեր՝

1. WiX տիպի (SimpleSampleWix)
2. Console application տիպի (SimpleSampleApp), այս նախագծին ավելացնում ենք մեկ տեքստային ֆայլ ևս readme.txt
3. Class library տիպի (SimpleSampleDll)

Մեր նպատակն է լինելու վերջին երկու նախագծերի ելքային տվյալների համար հավաքել WiX ելակետային նկարագրություն (SimpleSampleWix.wxs) և այնուհետև նրանից ստանալ Windows տեղակայվող տվյալների բազա (SimpleSampleWix.msi), որը թույլ կտա նշված ֆայլերը տեղակայել նպատակային համակարգչի առանձնահատուկ ֆայլապանակում:

Ինչքան էլ մեր ընտրած խնդիրը պարզ է, այնուամենայնիվ Windows Installer-ը մեզ մատուցելու է հոյակապ ծառայություններ՝ ներառյալ մեր ծրագրի ավտոմատ գրառումը Control Panel > Add or Remove Programs ցուցակում: Համոզված լինելու համար, որ Windows Installer-ը մեր ծռագրի մասին տեղեկություն է պահում, մենք նրան կապահովենք որոշակի տվյալներով: Թեև ամեն մի տեղակայվող մեծություն ունի իր առանձնահատուկ անունը, Windows Installer-ը լոկ անունից բացի պահանջում է նաև յուրահատուկ իդենտիֆիկատոր (GUID): GUID-ները ազատ են և կարող ենք ստեղծել այնքան ինչքան կամենանք: Նրանք թույլ կտան իդենտիֆիկացնել՝ նույնացնել տեղակայվող փաթեթների յուրաքանչյուր մասը: GUID-ները առանձնակի են և չեն կրկնվում: Կան GUID-ներ ստեղծելու շատ գուրծիքներ, այդ թվում նաև այս մեկը:

Եթե օգտագործվող գործիքը GUID-ները ստեղծում է փոքրատառերով, ապա նախքան WiX տեղափոխելը հարկավոր է նրանք կոնվերտացնել մեծատառերի:

Նկատենք, որ այստեղ տրվող օրինակներում, բոլոր GUID-ները անվավեր են, ուստի և նախքան օգտագործելը հարկավոր է փոխարինել նորաստեղծներով:

Ամենամինիմալ կառուցվածքը, որ կարող է ունենալ ելակետային .wxs ֆայլը հետևյալն է՝

<?xml version=’1.0′ encoding=’utf-8′?>
<Wix xmlns=’http://schemas.microsoft.com/wix/2006/wi’>

<Product
Id=’NEW-GUID-2FCA-44f9-8C4F-30906EF7DB74}’
Name=’Test Package’
Language=’1033′
Version=’1.0.0.0′
Manufacturer=’My Company’
UpgradeCode=’{NEW-GUID-6CC5-459a-9EE4-017209DCF888}’
>

<Package
Description=’My first Windows installer package’
Comments=’This is my first Windows installer package’
Manufacturer=’My Company’
InstallerVersion=’200′
Compressed=’yes’
/>

</Product>
</Wix>

Ինչպես տեսնում ենք սա դատարկ XML նկարագրության է: Հավասարման նշանների ձախ մասերի բոլոր անունները WiX սքրիպտային լեզվին առանձնահատուկ անուններ են, որոնցից յուրաքանչյուրը պետք է ստանա իր ճշգրիտ արժեքը` հավասարման աջ մասից:

XML նկարագրության այս պատառը կարելի է տեղափոխել WiX նախագծի .wxs ֆայլի մեջ, փոխարինել GUID-ները նորաստեղծներով ևWiX նախագծի վրա մկնիկի աջ կտտոցից բացված կոնտեքստային ցանկից ընտրել Build կամ Rebuild: Նախագծի կառուցումը պետք է որ ընթանա առանց սխալների ևWiX նախագծի ելքում կունենանք SimpleSampleWix.msi Windows տեղակայվող տվյալների բազան: Այն կարելի է գործարկել նպատակային համակարգչի վրա՝ Windows Installer-ը տեսնելով, որ նրա մեջ առանձնակի ոչ մի նկարագրություն չկա, համակարգիչը թողնում անփոփոխ:

Զարգացնելով վերևի XML նկարագրությունը ի օգուտ մեր նպատակի իրականացմանը մենք կարող ենք ունենալ՝

<?xml version=’1.0′ encoding=’utf-8′?>
<Wix xmlns=’http://schemas.microsoft.com/wix/2006/wi’>

<Product
Id=’NEW-GUID -2FCA-44f9-8C4F-30906EF7DB74′
Name=’SimpleSampleWix’
Language=’1033′
Version=’1.0.0.0′
Manufacturer=’My Company’
UpgradeCode=’NEW-GUID -6CC5-459a-9EE4-017209DCF888′
>

<Package
Description=’My first Windows installer package’
Comments=’This is my first Windows installer package’
Manufacturer=’My Company’
InstallerVersion=’200′
Compressed=’yes’
/>

<Media Id=”1″ Cabinet=”media1.cab” EmbedCab=”yes” />

<Directory Id=”TARGETDIR” Name=”SourceDir”>
<Directory Id=”ProgramFilesFolder”>

<Directory Id=”MyCompany” Name=”MyCompany”>
<Directory Id=”SimpleSampleWix” Name=”SimpleSampleWix”>

<Component Id=”SimpleSampleAppexe” Guid=”NEW-GUID -EFF6-428c-A90B-A405384DE4D9″>
<File Id=”SimpleSampleApp.exe” Source=”..\bin\$ (var.SimpleSampleApp.Configuration)\SimpleSampleApp.exe” />
</Component>

</Directory>
</Directory>
</Directory>

</Directory>

<Feature Id=”ProductFeature” Title=”SimpleSampleWix.Setup” Level=”1″>
<Feature Id=”SimpleSampleAppexe” Title=”SimpleSampleApp.exe” Description=”SimpleSampleApp.exe.” Level=”1″>
<ComponentRef Id=”SimpleSampleAppexe” />
</Feature>
</Feature>

</Product>
</Wix>

Այո, սա կլինի մեր առաջին իմաստալից WiX ելակետային նկարագրությունը, որը կարելի է տեղափոխել WiX նախագծի ելակետային ֆայլ և փորձարկել:
Ավելացնելով հետևյալ նկարագրությունները ևս՝

<Component Id=”readmetxt” Guid=”NEW-GUID -0995-453a-8D93-7F5AD9AD36AE”>
<File Id=”readme.txt” Source=”..\bin\$ (var.SimpleSampleApp.Configuration)\readme.txt” />
</Component>
<Component Id=”SimpleSampleDlldll” Guid=”NEW-GUID-AF42-4c86-8CC0-EA6297A22B32″>
<File Id=”SimpleSampleDll.dll” Source=”..\bin\$ (var.SimpleSampleDll.Configuration)\SimpleSampleDll.dll” />
</Component>
և
<Feature Id=”readmetxt” Title=”readme.txt” Description=”readme.txt” Level=”1″>
<ComponentRef Id=”readmetxt” />
</Feature>
<Feature Id=”SimpleSampleDlldll” Title=”SimpleSampleDll.dll” Description=”SimpleSampleDll.dll.” Level=”1″>
<ComponentRef Id=”SimpleSampleDlldll” />
</Feature>

կարող ենք վերջնականապես փորձարկել մեր ամբողջական լուծումը:

Նկատենք, որ $ (var.SimpleSampleDll.Configuration) և $ (var.SimpleSampleApp.Configuration) մեծությունների որոշման համար բավական է WiX նախագծի վրա մկնիկի աջ կտտոցից բացված կոնտեքստային ցանկից ընտրել Add Reference հրամանը և բացված պատուհանի օգնությամբ WiX նախագծին ավելացնել հղումներ մյուս երկու նախագծերին (SimpleSampleApp, SimpleSampleDll):

(Շարունակելի)

Windows Installer XML - ծրագրային գործիքների համախումբը (WiX) նախատեսված է Windows օպերացիոն համակարգում նոր ծրագրային միջոցների տեղակայվող փաթեթների (.msi տիպի ֆայլերի) կառուցման համար: WiX-ը արագացնում և հեշտացնում է նույնիսկ շատ բարդ կառուցվածք ունեցող տեղակայվող փաթեթների մշակումը:

WiX-ի մուտքային (ելակետային) տվյալներն իրենցից ներկայացնւմ են XML տիպի ձևավորված ֆայլեր գրված WiX սքրիպտային (ինտերպրետացվող) լեզվով: WiX-ը ապահովում է՝

• Windows-ի հրամանային տողի միջավայր, որտեղ օգտագործողը կարող է կատարել Makefile ոճի ինտեգրում:
• Ավելի նոր MSBuild տեխնոլոգիան՝ ներքուստ ինտեգրվելով այնպիսի ծրագրային միջոցների մշակման միջավայրերի հետ, ինչպիսիք են Microsoft Visual Studio-ն կամ SharpDevelop-ը:

WiX-ը բաց կոդով նախագիծ է (open source project)՝ սկզբնապես մշակված Microsoft-ի կողմից: Դուք կարող եք բեռնավորել երկուական և ելակետային ծրագրերը SourceForge-ից:

WiX-ը մշակվում է C#-ով և պահանջում է .NET Framework 2.0 և Service Pack 1՝ պատշաճ աշխատանքի համար: Նկատենք, որ սա վերաբերվում է միայն Տեղակայվող Բազաների մշակման միջավայրին: Տեղադրվող ծրագրային փաթեթը չի պահանջում որևէ հավելյալ միջավայր կամ ծրագիր նպատակային համակարգչի վրա տեղադրվելու համար:

WiX-ը մշակող ընկերասեր անձնակազմը սպասում է WiX-ին առնչվող Ձեր հարցերին ու առաջարկներին; Եթե դուք արդեն ունեք SourceForge հաշիվ ապա կարող եք օգտվել ՎԵԲ էջից, հակառակ դեպքում՝ ամենապարզ ճանապարհը դատարկ հաղորդագրություն ուղարկելն է այս հասցեով request@lists.sourceforge.net :

Ներածություն

Համակագչային ծրագրի մշակման ավարտը դեռ հեռու է նրա վերջնական ավարտից: Վերջին տարիներին պատվիրատուները ակնկալում են ստանալ պատշաճ ձևով գործող եզրափակիչ տեղակայվող արտադրանք: Եվ քանի որ ծրագրային միջոցների տեղակայման գործընթացը պատվիրատուների կողմից առաջին ծանոթությունն է, ապա չի կարելի թերագնահատել նրա հուսալիության կարևորությունը:

Ավանդական տեղակայման ծրագրային միջոցները օգտվում էին ծրագրային և սքրիպտային (սցենարային) եղանակներից՝ նկարագրելու համար այն բազմաթիվ գործողությունները, որ անհրաժեշտ են նպատակային մեքենայի վրա վերջնական ծրագրային արտադրանքի տեղակայմանը: Թվարկենք նրանցից ավելի հաճախ հանդիպողները՝

• Ֆայլերի տեղակայում,
• Գրանցում Windows-ի ռեգիստրում,
• Սարքերը ղեկավարող դրայվերների և Windows ծառայությունների տեղակայումը և ակտիվացումը:

Windows տեղակայման տեխնոլոգիաները, պատվիրատուների կողմից լինելով մշտական համեմատական ու զգացմունքային գործոնների ներքո, կրել են փիլիսոփայական բավականին լուրջ փոփոխություններ: Հիմնական փոփոխությունները վերաբերվում են հրամայականից դեկլարատիվ (հայտարարական) նկարագրության անցմանը: Առանձին քայլեր նկարագրելու փոխարեն հայտարարական մոտեցումը նկարագրում է նպատակային համակարգիչի իրավիճակը նրա վրա ծրագրային միջոցների (ԾՄ) տեղակայման կամ հեռացման գործընթացի տարբեր փուլերում: Հրամայական մոտեցումը թվում է բավականաչափ լիարժեք քանի դեռ ինչ-որ սխալ տեղի չի ունեցել: Հայտարարական եղանակը հնարավորություն է ընձեռում պատրաստ լինելու անսպասելի իրավիճակներում իր պատշաճ ու անխափան պահվածքին՝

1. տարբերակելով նպատակային համակարգիչի միջավայրը,
2. տարբերակելով ընդհատված տեղակայումները,
3. զանազանելով բաշխված ռեսուռսները,

Տեղակայվող բազաների մշակողների համար կարևոր նշանակություն ունի համոզված լինել նրանում, որ ինչ էլ պատահի տեղակայման ընթացքում, նպատակային համակարգիչը կմնա տեղեկացված և կայուն իրավիճակում՝ չառաջացնելով ոչ մի այլ կողմնակի էֆեկտ:

WiX-ը, որ մենք պատրաստվում ենք նկարագրել, օգտագործում է սկզբունքորեն այլ մոտեցում: Գրաֆիկական ինտերֆեյսի փոխարեն, որը ծրագրավորողներին թույլ է տալիս հավաքելու ֆայլեր և այլ անհրաժեշտ պարագաներ, այն առավել նման է ծրագրավորման լեզվի: Կատարելապես ինտեգրվելով ծրագրերի մշակման սովորական ընթացքին, այն օգտագործում է տեքստային ֆայլեր (հիմնվելով ավելի ու ավելի հանրահայտ դարձող XML ֆորմատի վրա) տեղակայվող բոլոր տարրերի տեղակայման գործընթացը նկարագրելու համար: WiX-ը ունի կոմպիլյատոր և կազմավորիչ որոնց օգնությամբ ստեղծվում է տեղակայվող բազան: WiX-ը շատ հեշտությամբ կարելի է դարձնել ցանկացած ավտոմատացված կառուցման համակարգի մասը:

Ի հավելումն այս ինտեգրվող հատկությանը, WiX-ն առաջարկում է մեկ այլ ինտեգրացման մակարդակ: Ավանդաբար, տեղադրման ծրագրերը մշակվում էին, երբ հիմնական ծրագրերի մշակումը ավարտվում էր: Այս մոտեցումը հղի է ինֆորմացիայի հավաքման գործընթացում սխալների բերմանը: WiX-ը առաջարկում է տեղադրվող տարրերը հավաքել հիմնական ծրագրային միջոցների մշակմանը զուգընթաց՝ քայլ առ քայլ: Հենց որ կսկսվի նոր մոդուլի մշակումը, կամ կպահանջվի, օրինակի համար, Windows-ի ռեգիստռում կատարել նոր գրառում, զուգահեռաբար հարկավոր կլինի կատարել համապատասխան նոր գրառումներ տեղակայող ծրագրում: Կիրառելով այս մոտեցումը՝ ոչ մի կարևոր ինֆորմացիա երբևէ բաց չի թողնվի և տեղադրման ծրագիրը գործնականորեն ավարտված կլինի հիմնական ծրագրի հետ միաժամանակ:

Որպես հետևանք՝ WiX-ը չի պահանջում ծրագրավորողների կողմից փաթեթի ծրագրային բարձր մակարդակի իմացություն:

Ամփոփելով՝ WiX-ի հատկությունների ու առավելությունների շարքում կարող ենք նշել՝

• դեկլարատիվ (հայտարարական) բնույթ,
• Windows տեղադրող ծրագրի ֆունկցիոնալությանը մոտենալու անսահմանափակ իրավունք,
• գրաֆիկական ինտերֆեյսի փոխարեն տեքստային տեղակայման ծրագիր,
• ավտոմատացված կառուցման համակարգի հետ կատարյալ ինտեգրման հնարավորություն,
• ծրագրի մշակման հետ ինտեգրացման հնարավորություն,
• թիմային մշակման հնարավորություն,
• բաց կոդով ծրագիր:

(Շարունակելի)

Հաճելի ընթերցում…