Namestitveni program zaganjalnika 2.0

Od različice 2.0 zaganjalnik aplikacijo namesti za uporabnika sistema Windows tako, kot Windows Installer namesti paket za posameznega uporabnika: na podlagi opisa njenih sestavnih delov, kot eno transakcijo, ki se ob napaki povrne, in s štetjem uporab vsakega skupnega dela. Posodobitev, vrnitev na prejšnjo različico, popravilo in odstranitev zato pustijo natanko tisto stanje, ki ga obljubljajo. Nič od tega ne zahteva skrbniških pravic.

registration.json vsebuje registracijo knjižnice DLL za posameznega uporabnika v obliki podatkov; zapiše se ob gradnji paketa (tools\Export-Registration.ps1 iz knjižnice WKL Forms Object Library). Zaganjalnik te ključe zapiše sam, namesto da bi zagnal regsvr32. Windows Installer samoregistracijo odsvetuje, ker je ni mogoče zanesljivo povrniti in ker ni vidno, kaj zapiše.

Vsak del nameščene različice je komponenta s ključno potjo; komponenta je nameščena, če njena ključna pot obstaja. Vsaka različica izdelka, ki komponento uporablja, je eden od njenih odjemalcev; na tem temelji štetje uporab.

Vse to je zabeleženo v podatkovni zbirki namestitvenega programa, %LOCALAPPDATA%\WKL\Installer\installer.db (SQLite, in sicer različica, ki je del sistema Windows; ena podatkovna zbirka za vse izdelke uporabnika). Njene tabele:

Kako to preverite od zunaj.

• Wkl.Bootstrapper.exe /list izpiše vse nameščene različice in vse komponente s številom njihovih uporabnikov; komponenta, ki ji manjka ključna pot, je označena z MISSING (repair: /repair). /list /json izpiše isto v obliki JSON (glejte Ukazi in izhodne kode).
• Podatkovno zbirko lahko berete s katerim koli orodjem za SQLite, na primer SELECT * FROM ComponentClient, vendar samo berete: vanjo piše izključno zaganjalnik.
• Dnevnik izdelka (Logs\bootstrapper.log) ima za vsak korak eno vrstico: datum in čas z milisekundami, ID procesa, korak, dopolnjen na 12 znakov, nato besedilo. Za vsako namestitev zaganjalnik zapiše vrstico s korakom install: za izdajo formata 1 install <version> <copy>, ki ji sledi components <release>, če so bile registrirane komponente; za projekt formata 2 install <product> <version>: <n> entries, <n> registry keys. Izdaja, ki uporabi obstoječo registracijo, namesto tega zapiše components using the existing registration ....

Zagon z novo različico (ali prvi zagon) izvede te korake kot eno transakcijo:

1. Najprej se povrne prejšnja prekinjena transakcija (računalnik se je izklopil, proces je bil končan).
2. Ob prvem srečanju z izdelkom se prevzame, kar je namestil zaganjalnik 1.0 (glejte spodaj).
3. Različica se zabeleži.
4. Če kopija še ne obstaja, se ustvari: datoteka se kopira, preveri glede na velikost in vrednost SHA-256 iz app-manifest.json (koda 42, če se razlikuje) in se ji odstrani oznaka, da izvira s spleta; zapiše se datoteka INI.
5. Komponente: obstoječa registracija, ki je ni naredil zaganjalnik (registracija oddelka IT za ves računalnik v HKLM ali lastna registracija paketa različice za uporabnika) in ki kaže na obstoječo knjižnico DLL vsaj tiste različice, ki jo zahteva aplikacija (requires v app-manifest.json), se uporabi takšna, kot je. Ponovna registracija bi jo podvojila, COM pa bi dal uporabnikovi registraciji prednost pred novejšo registracijo računalnika. Sicer odloči pravilo različic; mapa različice, ki jo je treba registrirati, se kopira (samo manjkajoče datoteke; knjižnica DLL, ki je v uporabi, se nikoli ne zamenja), registracija pa se zapiše iz registration.json.
6. Gonilniki ODBC iz izdaje, vsak s svojim virom podatkov (glejte Gonilniki ODBC).
7. Zaupanja vredno mesto in vnos v Aplikacijah se zapišeta ali posodobita (DisplayVersion).
8. Transakcija se potrdi.

Nato se v ločeni transakciji odstranijo različice nad keepVersions (nikoli tista, ki se zaganja, in nikoli nazadnje delujoča), potem pa se zažene Access. Različica, ki se uspešno zažene, postane nazadnje delujoča.

Ob napaki se vsak doslej opravljen korak razveljavi v obratnem vrstnem redu; računalnik je v enakem stanju kot pred zagonom, okno pa sporoči kodo:

Če datoteko uporablja drug program (protivirusni program, indeksiranje), koraki z datotekami kratek čas počakajo in poskusijo znova.

Primer: oddelek IT je komponente registriral za računalnik. Komponente knjižnice WKL Forms Object Library 1.56 so registrirane pod HKLM, knjižnica DLL pa je v C:\Program Files (x86)\WKL\Access Components; aplikacija zahteva 1.51, izdaja pa prinaša 1.56.1. Zaganjalnik ne registrira ničesar, ne kopira komponent in ne zabeleži komponente components/...; v dnevniku je zapisana vrstica components using the existing registration 1.56 for the computer: C:\Program Files (x86)\WKL\Access Components\Wkl.Access.Components.dll. Če bi bila registracija za računalnik 1.48, bi se za uporabnika registrirala izdana različica 1.56.1 in odtlej bi imela uporabnikova registracija prednost pred registracijo računalnika.

Za posameznega uporabnika je v 32- in v 64-bitnem pogledu registra registrirana po ena različica WKL Forms Object Library: ključi razredov so v vseh različicah enaki, zato zadnja registracija velja za vse uporabnikove aplikacije. Pri vsaki različici izdelka je zabeležena različica komponent, ki jo zahteva njena aplikacija (requires v app-manifest.json). Zaganjalnik registrira izdano različico, razen če bi s tem drugemu izdelku vzel različico, ki jo ta potrebuje:

Štejejo samo drugi izdelki. Različice istega izdelka, ki ostanejo poleg zagnane (keepVersions), ne štejejo: ob vrnitvi na prejšnjo različico izdelka se registrira različica komponent, s katero je bila ta izdana, ob prehodu naprej pa znova novejša. Primer: izdelek A 1.4.0 zahteva 1.56 in je bil izdan z 1.56.1, A 1.5.0 zahteva 1.57 in je bil izdan z 1.57.0.

Če dva izdelka zahtevata različni različici, zato oba uporabljata višjo. Ko se registracija spremeni, Access, ki že teče, obdrži knjižnico DLL, ki jo je naložil, pozneje zagnani procesi Access pa naložijo na novo registrirano različico.

Različica komponent je vrednost release iz njihovega registration.json, ki jo Export-Registration.ps1 vzame iz različice izdelka datoteke Wkl.Forms.ObjectLibrary.Managed.dll (do izdaje 1.68: Wkl.Access.Components.Managed.dll; na primer 1.56.1). Podatki o različici v nativnem zagonskem modulu (Wkl.Forms.ObjectLibrary.dll, do izdaje 1.68 Wkl.Access.Components.dll) vsebujejo samo glavno in podrejeno številko (1.56.0 v 1.56.1) in se ne uporabljajo; zaganjalnik 1.0 jih je uporabljal, zato imajo lahko njegove mape pod Components to številko.

Izdaja lahko prinese gonilnike ODBC za uporabnika, tako da jih ni treba nameščati nobenemu skrbniku. Vsak gonilnik je v izdaji v mapah odbc\<driver>\x86 in odbc\<driver>\x64 ter je naveden v bootstrapper.json:

{
  "format": 1,
  "product": "Stranke",
  "source": "\\\\server\\apps\\kunden\\production",
  "components": "components",
  "odbcDataSources": [ "WklGateway" ],
  "odbc": [
    { "driver": "Wkl OData", "folder": "odbc\\Wkl OData", "dll": "Wkl.Data.OData.Odbc.dll", "dataSource": "WklGateway" }
  ]
}

Zaganjalnik podmapo kopira v %LOCALAPPDATA%\WKL\Drivers\<driver>\<release>\<bitness>, kjer je <release> različica izdelka knjižnice DLL brez oznake gradnje, in za uporabnika zapiše vir podatkov (za x86 v 32-bitnem pogledu registra):

Vnos v ODBCINST.INI se ne zapiše; Access odpre povezane tabele in prepustne poizvedbe prek vira podatkov, katerega Driver je pot do knjižnice DLL. Vse drugo – naslov storitve, podatkovna zbirka – sodi v povezovalni niz povezav aplikacije, ne v vir podatkov. Vir podatkov, naveden v odbc, mora obstajati šele po zagonu; drugi vnosi v odbcDataSources morajo obstajati že prej.

Gonilnik je komponenta s štetjem uporab, tako kot komponente WKL: novejša različica, izdana pozneje, se namesti poleg stare, vir podatkov pa nato kaže nanjo. Mapa različice in vir podatkov se odstranita skupaj z zadnjo različico izdelka, ki ju uporablja. Vir podatkov s tem imenom, ki je obstajal že, preden ga je zapisal zaganjalnik, se vrne na prejšnje vrednosti.

Za razliko od komponent WKL za vir podatkov ne velja pravilo različic: vsak zagon ga zapiše za zagnano različico. Vrnitev na različico, izdano s starejšim gonilnikom, vir podatkov znova usmeri na ta starejši gonilnik. Če dva izdelka izdata isti dataSource z različnima različicama gonilnika, odloči izdelek, ki je bil zagnan nazadnje; koda se ne sporoči, obe mapi pa ostaneta, dokler ju uporablja katera koli različica. Če si izdelka različice gonilnika ne smeta deliti, dajte vsakemu lasten dataSource.

Ko vir znova ponuja nižjo različico, jo zagon znova namesti: njeno kopijo (če še obstaja), njene gonilnike (vir podatkov znova kaže na starejši gonilnik) in njeno različico komponent po pravilu različic. Novejše različice ostanejo, dokler jih ne odstranita keepVersions ali odstranitev izdelka, zato se uporabnik lahko pozneje spet premakne naprej.

Če projektna datoteka vsebuje deliveryKey, se nižja različica iz vira namesti samo, če je založnik višjo umaknil v podpisani izdaji (/publish /withdraw); sicer zaganjalnik obdrži nameščeno različico in sporoči kodo 52. Glejte Objava podpisane izdaje.

Na prejšnjo različico se lahko vrnete tudi takrat, ko vir že ponuja novejšo, in sicer v oknu z nastavitvami (Wkl.Bootstrapper.exe /settings). Njegova tri dejanja tečejo prek namestitvenega programa, vsako kot ena transakcija s svojo povrnitvijo:

Zaženi to različico vrne različico komponent, ki jo je različica izdelka uporabljala, ne tiste, ki jo je vsebovala njena izdaja. Če je različica izdelka uporabljala novejše komponente, ker jih je potreboval drug izdelek, ostanejo registrirane te novejše komponente.

Za izdelek, ki ga je namestil samo zaganjalnik 1.0, veljajo za njegove mape dejanja različice 1.0, dokler ga naslednji zagon ne prevzame.

Wkl.Bootstrapper.exe /repair izvede namestitev trenutne različice, ne da bi zagnal Access: vse, kar manjka, se obnovi iz izdaje – kopija, če je bila izbrisana, datoteke komponent, izbrisane ali spremenjene vrednosti v registru, zaupanja vredno mesto in vnos v Aplikacijah. Kar je že na mestu, ostane nespremenjeno; obstoječa kopija obdrži uporabnikove podatke.

Wkl.Bootstrapper.exe /uninstall (to je tudi ukaz, ki ga Windows zažene iz Nastavitev › Aplikacije) kot eno transakcijo odstrani:

• vse različice izdelka: mape različic z vsem, kar je v njih;
• vsako komponento, ki je ne uporablja nobena druga različica izdelka uporabnika: datoteke, mape ter ključe in vrednosti registra, ki jih je ustvaril zaganjalnik;
• vrednosti v registru, ki so obstajale, preden jih je zapisal zaganjalnik, se vrnejo na prejšnjo vsebino, nikoli se ne izbrišejo;
• zaupanja vredno mesto in vnos v Aplikacijah.

Komponente, ki jih še uporablja drug uporabnikov izdelek, ostanejo, z njimi pa tudi skupni ključi razredov. Če je odstranjeni izdelek uporabljal registrirano različico, se znova registrira najnovejša preostala različica (32- ali 64-bitna, enako kot prej). Če je kopija odprta v programu Access, se ne odstrani nič, koda pa je 41 z navedbo programa; zaprite Access in ukaz zaženite znova.

Bližnjice s seznama shortcuts projekta se odstranijo skupaj z izdelkom, tudi tiste, katerih cilj je sam zaganjalnik.

Nespremenjeni ostanejo: mapa, iz katere teče zaganjalnik, z datoteko bootstrapper.json, bližnjice, ki ne izvirajo iz projekta, sama podatkovna zbirka namestitvenega programa in dnevniki pod %LOCALAPPDATA%\WKL\<product>\Logs.

Kode so enake kot na strani Kode napak zaganjalnika. /list /json izpiše en objekt:

{
  "versions": [
    { "product": "Stranke", "displayName": "Stranke", "version": "1.4.0", "lastWorking": true }
  ],
  "components": [
    { "id": "components/1.56.1/x86", "keyPath": "C:\\Users\\<user>\\AppData\\Local\\WKL\\Components\\1.56.1\\x86\\Wkl.Access.Components.dll", "clients": 2, "present": true }
  ]
}

Če ni nameščeno nič, sta polji prazni.

Če želite povrnitev videti na preizkusnem računalniku, povzročite, da kopiranje ne uspe, potem ko je bila različica že zabeležena:

1. Zaženite /list /json in shranite izpis.
2. V vir shranite novo različico in v njeni datoteki podatkovne zbirke spremenite en bajt, potem ko je bil zapisan app-manifest.json.
3. Zaženite zaganjalnik. Sporoči kodo 42.
4. Znova zaženite /list /json: izpis je enak kot v 1. koraku, pod Frontends pa ni mape nove različice.

Če želite videti, da se povrneta tudi registracija komponent in vir podatkov, povzročite, da ne uspe korak, ki sledi za njima. Gonilnik se namesti za komponentami (6. korak za 5. korakom), zato je primerna izdaja z vnosom odbc:

1. Zaženite /list /json in si zapišite vrednosti ključa razreda komponent (na primer HKCU\Software\Classes\WklForms.Application\CLSID, do izdaje 1.68 WklComponents.Application, in njegovega InprocServer32) ter ključa HKCU\Software\ODBC\ODBC.INI\<dataSource>.
2. V vir shranite novo različico, katere izdaja prinaša novejšo različico komponent in gonilnik.
3. Izdano knjižnico DLL gonilnika imejte odprto tako, da je ni mogoče prebrati, na primer v lupini PowerShell: $f = [System.IO.File]::Open('<source>\odbc\<driver>\x86\<dll>', 'Open', 'Read', 'None').
4. Zaženite zaganjalnik. Po nekaj sekundah ponovnih poskusov sporoči kodo 41.
5. Primerjajte: /list /json, ključ razreda in vir podatkov so enaki kot v 1. koraku; pod %LOCALAPPDATA%\WKL\Components ali %LOCALAPPDATA%\WKL\Drivers ni mape nove različice.
6. Sprostite datoteko ($f.Dispose()) in znova zaženite: nova različica se namesti.

Pravilnik, ki prepoveduje zaupanja vredna mesta, za ta namen ni primeren: zaganjalnik ga preveri, preden karkoli namesti (koda 50 brez transakcije), ključev pravilnika pod HKCU\Software\Policies pa brez skrbniških pravic ni mogoče zapisati.

Če želite videti, da odstranitev izdelka ne odstrani samo napol, odprite nameščeno kopijo v programu Access in zaženite /uninstall /quiet: koda 41 navede MSACCESS.EXE, /list pa še vedno prikaže vse različice in komponente.

Ko različica 2.0 prvič naleti na izdelek, kot svoje zabeleži, kar je namestil zaganjalnik 1.0: mape različic pod Frontends (nazadnje delujočo različico iz State\provisioning.json), zaupanja vredno mesto, ki ga je zapisala različica 1.0 (njen opis se konča z (Wkl.Bootstrapper)), in registracijo, ki jo je različica 1.0 naredila z regsvr32 iz %LOCALAPPDATA%\WKL\Components. Ti deli se nato počistijo in odstranijo kot deli, ki jih je namestila različica 2.0. Registracije iz drugih virov se ne prevzamejo.

• Dva zaganjalnika istega uporabnika sistema Windows, ki nameščata hkrati, se med seboj ne uskladita: podatkovna zbirka namestitvenega programa je ena na uporabnika, zaganjalnik, ki najde nedokončano namestitev, pa jo povrne, tudi če jo izvaja drug zaganjalnik. Zaženite ju enega za drugim (format 1 brez registration.json se uskladi po izdelkih).
• Z datoteko formata 1 okolja .NET Desktop Runtime ni mogoče izdati: zaganjalnik ga samo preveri (koda 33). Projekt formata 2 lahko izda zasebno izvajalno okolje; glejte Zasebno izvajalno okolje .NET v izdaji.
• WKL JSON z datoteko formata 1 ni izdan: aplikacija, ki ga uporablja, potrebuje vnaprejšnjo registracijo, na primer s strani oddelka IT. Projekt formata 2 ga izda kot vnos registerCom, enako kot kateri koli strežnik COM.
• Računalniki, ki programe v uporabnikovem profilu omejujejo z AppLockerjem ali s funkcijo Windows Defender Application Control, niso podprti.
• Vir prek protokola HTTP/HTTPS ni podprt; vir je mapa ali skupna raba.

• Projektna datoteka (format 2)
• Objava podpisane izdaje
• Ustvarjanje projekta iz predlog
• Zasebno izvajalno okolje .NET v izdaji
• Kaj zaganjalnik zapiše in sporoči (1.0.1)
• Odstranitev aplikacije iz računalnika (1.0.1, ročno)
• Kode napak zaganjalnika