Global Cache de asamblare

Global Cache de asamblare

Acum știm cum să construim ansambluri cu un nume strict - este timpul să învățăm cum să implementăm astfel de ansambluri și cum CLR utilizează metadate pentru a găsi și încărca ansamblul.







Dacă ansamblul este destinat să fie împărțit de mai multe aplicații, acesta trebuie plasat într-un director bine-cunoscut, pe care CLR ar trebui să-l verifice automat pentru a găsi legătura cu ansamblul. Locul în care se află ansamblurile partajate se numește cache globală de asamblare (GAC). De obicei, acest director este C: \ Windows \ Assembly (presupunând că Windows este instalat în directorul C: \ Windows).

GAC are o structură specială și conține multe directoare imbricate ale căror nume sunt generate de un anumit algoritm. În niciun caz nu trebuie să copiați manual fișierele de asamblare la GAC ​​- în schimb, trebuie să utilizați instrumentele create special pentru acest scop. Aceste instrumente "cunosc" structura internă a GAC ​​și sunt capabile să genereze denumirile corespunzătoare ale subdirectoarelor.

În timpul dezvoltării și testării ansamblurilor cu nume puternice, instrumentul GACUtil.exe este folosit cel mai adesea pentru a le instala în directorul GAC. Rularea fără parametri afișează următoarele informații:

Apelarea utilitarului GACUtil.exe cu opțiunea / i, puteți instala ansamblul în directorul GAC și dacă specificați parametrul / u, ansamblul va fi eliminat din GAC. Rețineți că un ansamblu cu un nume strict nu poate fi plasat în GAC. Dacă treci GACUtil.exe cu fișier de asamblare numit laxe, instrumentul va afișa următorul mesaj de eroare (eroare la adăugarea de asamblare în memoria cache: încercare de a instala un ansamblu fără un nume puternic):

Notă. În mod implicit, numai membrii grupului Admistratori Wi-Fi (administratori) sau Power Users pot manipula directorul GAC. GACUtil.exe nu va putea instala sau elimina ansamblul dacă utilizatorul care invocă utilitarul nu se află în acest grup.

Parametrul / i al utilitarului GACUtil.exe este foarte util pentru dezvoltator în timpul testării. Cu toate acestea, atunci când utilizați GACUtil.exe pentru a implementa un ansamblu într-un mediu de producție, este recomandat să utilizați opțiunea / r în plus față de / i atunci când instalați și / u când scoateți ansamblul. Comutatorul / r asigură integrarea ansamblului cu mecanismul de instalare și dezinstalare a programelor Windows. De fapt, utilitarul invocat cu acest parametru spune sistemului care aplicație cere acest ansamblu și îl asociază cu acesta.

Notă. În cazul în care ansamblul cu un nume puternic este ambalat în fișierul CAB este comprimat sau în orice alt mod, atunci, înainte de a instala un fișier de asamblare în directorul CAG folosind utilitarul GACUtil.exe pentru al decomprima într-un fișier temporar, care trebuie să fie eliminate după uzina de asamblare.

Utilitarul GACUtil.exe nu face parte din distribuția gratuită a NET Framework, destinată utilizatorului final. Dacă aplicația are ansambluri care trebuie implementate în directorul GAC, utilizați programul Windows Installer (MSI), deoarece este singurul instrument care poate instala ansambluri în GAC și este garantat că este prezent pe mașina utilizatorului final.

De ce "înregistrați" ansamblul în directorul GAC? Imaginați-vă că două companii au realizat fiecare dintre propriile ansambluri Calculus, constând dintr-un singur fișier: Calculus.dll. Evident, aceste fișiere nu pot fi scrise în același director, deoarece ultimul fișier copiat va suprascrie primul și astfel va întrerupe funcționarea unei anumite aplicații. Dacă utilizați un instrument special pentru a instala în GAC, acesta va crea foldere separate în directorul C: \ Wi-dows \ Assembly pentru fiecare dintre aceste ansambluri și va copia fiecare ansamblu în folderul propriu.

În mod obișnuit, utilizatorii nu navighează în structura directorului GAC, deci pentru dvs. nu contează. Doar faptul că structura cataloagelor GAC este cunoscută de CLR și de instrumentele care lucrează cu GAC.

Construiți un ansamblu care se referă la un ansamblu cu un nume puternic

Indiferent de asamblarea pe care o construiți, rezultatul este întotdeauna un ansamblu care se referă la o altă ansamblu cu un nume puternic. Această declarație este adevărată, numai dacă clasa System.Object este definită în MSCorLib.dll, un ansamblu cu un nume strict. Cu toate acestea, este probabil ca ansamblul să se refere și la tipuri din alte ansambluri cu nume puternice emise de Microsoft, dezvoltatori terți sau creați în organizația dvs. Capitolul 2 prezintă modul de utilizare a compilatorului CSC.exe cu parametrul / referință pentru a determina ansamblul pe care ansamblul asamblat trebuie să îl facă referitor. Dacă specificați calea completă la numele fișierului împreună cu numele fișierului, CSC.exe încarcă fișierul specificat și utilizează metadatele pentru a construi ansamblul. După cum sa menționat în capitolul 2, dacă specificați numele fișierului fără o cale, csc.exe încercând să găsească adunarea în următoarele directoare (prin vizualizarea acestora în ordinea în care apar aici, în Ka com).

1. Director de lucru.
2. Directorul unde este localizat fișierul CSC.exe. Acest director conține, de asemenea, un CLR DLL.
3. Directoare specificate de opțiunea de linie de comandă / li b atunci când sunați CSC.exe.
4. Directoare specificate în variabila de mediu LIB.

Deci, pentru a construi un ansamblu care face referire la fișierul System.Drawing.dll Microsoft, puteți seta / referință: System.Drawing.dll când sunați CSC.exe. Compilatorul va verifica directoarele listate și va găsi fișierul System.Drawing.dll în același director ca și fișierul CLR, pe care el însuși îl folosește pentru a crea ansamblul. Cu toate acestea, deși ansamblul este în acest director când este compilat, la runtime acest ansamblu este încărcat dintr-un alt director.

În timpul instalării .NET Framework, toate fișierele de asamblare create de Microsoft sunt instalate în două instanțe. Un set de fișiere este stocat într-un singur director cu CLR, iar celălalt în directorul GAC. Fișierele din CLR ușurează legarea ansamblurilor personalizate, iar copiile lor în GAC sunt proiectate să fie încărcate în timpul execuției.

Utilitarul CSC.exe nu caută construiturile necesare în GAC, astfel încât să nu trebuie să specificați căi greoaie la fișierele de asamblare. CSC.exe vă permite, de asemenea, să specificați ansamblurile utilizând un șir de formă egal de lung, dar ușor mai elegant:

Ambele metode sunt atât de stângace încât a fost decis să le preferăm să instaleze două copii ale fișierelor de asamblare pe hard disk-ul utilizatorului.

Notă. Când construiți un ansamblu, uneori trebuie să vă referiți la un alt ansamblu care există în două versiuni - x86 și x64. Din fericire, subdirectoarele din directorul GAC pot stoca versiuni x86 și x64 ale aceluiași ansamblu. Dar, deoarece aceste ansambluri au un singur nume, ele nu pot fi plasate în același director ca CLR. Dar nu contează, atunci când instalați versiunile .NET Framework ale ansamblurilor x86, x64 sau IA64 sunt instalate în directorul CLR. Când construiți un ansamblu, vă puteți referi la orice versiune a fișierelor instalate anterior, deoarece toate versiunile conțin aceleași metadate și diferă doar în cod. La timpul de execuție, versiunea necesară a ansamblului va fi încărcată din subdirectorul GAC_32 sau GACJ54. Mai târziu, în acest capitol, arătăm cum, în timp ce rulează, CLR determină unde să descarce ansamblul.

Stabilitatea ansamblurilor cu nume stricte pentru modificări neautorizate







Semnarea unui fișier cu o cheie privată asigură că titularul cheii publice corespunzătoare este producătorul ansamblului. Când se instalează un ansamblu în GAC, sistemul calculează hash-ul conținutului fișierului cu manifestarea și compară valoarea primită cu semnătura digitală a RSA încorporată în fișierul PE (după extragerea semnăturii cu cheia publică). Identitatea valorilor înseamnă că conținutul fișierului nu a fost modificat și că cheia publică a semnăturii corespunde cheii private a editorului. În plus, sistemul calculează hash-ul conținutului altor fișiere de asamblare și compară valorile primite cu cele ale tabelului manifestat Fi l eef. Dacă cel puțin una dintre valori nu se potrivește, atunci cel puțin unul dintre fișierele de asamblare a fost modificat și instalarea ansamblului în directorul GAC eșuează.

Notă. Acest mecanism garantează numai inviolabilitatea conținutului dosarului; editorul garantează autenticitatea editorului numai dacă sunteți absolut sigur că aveți o cheie deschisă creată de editor și că cheia privată a editorului nu a fost compromisă. Dacă editorul dorește să-și asocieze acreditările cu ansamblul, acestea trebuie să utilizeze în plus tehnologia Microsoft Authenticode.

Atunci când aplicația trebuie să se lege la adunarea la care se referă, CLR folosește pentru a găsi această adunare în GAC proprietățile sale (nume, versiune, standardele regionale și a cheii publice). Dacă se găsește ansamblul dorit, calea către directorul în care se află este returnată și fișierul cu manifestul său este încărcat. Un astfel de mecanism pentru a găsi ansambluri garantează părții care a sunat că, la momentul executării, va fi încărcat asamblarea editorului care a creat ansamblul din care a fost compilat programul. Această garanție este posibil datorită jetonul cheie publică corespunzătoare stocată în AssemblyRef referire tabelul de asamblare, cheia publică a tabelelor de asamblare AssemblyDef care se face referire. În cazul în care apelantul nu este în adunarea RGA, CLR va arata mai întâi pentru ea în directorul de bază al aplicației, și apoi verifică toate căile închise specificate în fișierul de configurare, apoi, în cazul în care aplicația este instalată cu ajutorul MSI, CLR cere MSI pentru a găsi ansamblul de dreapta. Dacă nici una dintre aceste opțiuni nu se construiește, legarea eșuează și o excepție este aruncată. System.IO.Fi l eNotFoundException.

Notă. Când un ansamblu cu nume puternic este încărcat din directorul GAC, sistemul asigură că fișierele care conțin manifestul sunt rezistente la modificări neautorizate. Această verificare are loc o singură dată în timpul fazei de instalare. Pentru a îmbunătăți performanța, CLR nu verifică dacă fișierele au fost modificate neautorizat și le încarcă într-un domeniu de aplicații cu drepturi depline. În același timp, atunci când ansamblul cu un nume puternic nu este descărcat din catalogul GAC, CRJ de execuție verifică fișierul manifest de asamblare pentru a vă asigura că acesta este rezistent la modificări neautorizate, luând timp suplimentar pentru a verifica de fiecare dată când descărcați acest fișier.

Atunci când se încarcă un ansamblu cu un nume puternic, nu din GAC, ci dintr-un alt director (directorul de aplicații sau directorul specificat de valoarea elementului codeBase din fișierul de configurare), CLR verifică hash-ul. Cu alte cuvinte, în acest caz, calculul hash-ului pentru fișier este efectuat de fiecare dată când aplicația este lansată. Deși performanța este oarecum redusă, fără astfel de măsuri, nu se poate garanta că conținutul ansamblului nu a fost supus unor modificări neautorizate. Atunci când hash-ul nu corespunde timpului de execuție, CLR aruncă un System.IO.File L oadException.

Mai devreme în acest capitol, am discutat cum să obținem o pereche de chei criptografice folosind utilitarul SN.exe. Acest utilitar generează chei, invocând funcții furnizate de interfața API criptografică Microsoft numită CryptoAPI. Cheile care rezultă pot fi stocate în fișiere de pe orice dispozitive de stocare. De exemplu, în organizații mari (cum ar fi Microsoft), cheile private generate sunt stocate pe dispozitivele hardware în seifuri, iar doar câteva persoane din personalul companiei au acces la chei private. Aceste măsuri de precauție împiedică cheia privată să compromită și să asigure integritatea acesteia. Ei bine, o cheie publică, desigur, este în general disponibilă și distribuită în mod liber.

Pregătiți-vă pentru a construi un ansamblu cu un nume puternic, trebuie să îl semnați cu o cheie privată. Cu toate acestea, dezvoltarea și testarea ansamblului este foarte incomod și apoi pentru a extrage cheia privată care este stocată „în spatele șapte sigilii“, astfel încât .NET cadru sprijină amânată (semnarea întârziată) sau parțială (semnare parțială), semnarea. Înregistrarea amânată vă permite să construiți un ansamblu cu cheie publică a companiei, fără a cere o cheie privată. Cheia publică vă permite să încorporați tabelele AssemblyRef de asamblare de înregistrare, link-ul de asamblare dvs., dreptul de a primi o valoare cheie publică, precum și în mod corect localizați ansamblul în structura internă a RGA. Fără a semna un fișier cheie privată, ai pierdut complet protecția împotriva modificărilor neautorizate, deoarece acest lucru nu este calculată hash construi și semnătura digitală nu este inclusă în fișierul. Cu toate acestea, în această etapă, aceasta nu este o problemă, deoarece ansamblul este amânat doar pentru perioada de dezvoltare, iar ansamblul gata pentru ambalare și implementare este semnat cu o cheie privată.

De obicei, cheia publică a companiei este primită ca fișier și transferată către utilitățile care construiesc ansamblul. (După cum sa menționat mai devreme în acest capitol, pentru a extrage cheia publică din fișierul care conține perechea de chei, puteți apela utilitarul SN.exe cu opțiunea -p.) De asemenea, trebuie să specifice asamblează de asamblare gram pro care semnarea va fi întârziată, că este cel care va fi configurat fără o cheie privată. În compilatorul C #, parametrul / delaysign este utilizat pentru acest lucru. În Visual Studio, în fereastra de proprietăți a proiectului, accesați fila Sigipg și bifați caseta de selectare Opțiune sigla întârziere. Atunci când utilizați utilitarul AL.exe, trebuie să specificați parametrul / semn de întârziere [semn].

Dacă descoperiți că ansamblul este amânat, compilatorul sau utilitarul AL.exe generează o intrare de chei publice în tabela metadatelor AssemblyData. Ca de obicei, prezența cheii publice vă permite să plasați ansamblul în GAC, precum și crearea unor alte ansambluri care se leagă de acesta, în timp ce ei au tabelul AssembyRef înregistrările de metadate va corecta valoarea cheii publice. La asamblarea unui ansamblu în fișierul PE rezultat, există loc pentru semnătura digitală a RSA. (Utilitarul de compilare determină dimensiunea spațiului liber necesar pe baza dimensiunii cheii publice.) Apropo, de data aceasta nu se calculează hash-ul fișierului.

În acest moment, ansamblul rezultat nu are o semnătură digitală validă. O încercare de a instala un astfel de ansamblu în GAC va eșua, deoarece hash-ul conținutului fișierului nu a fost calculat, ceea ce creează apariția corupției fișierului. Pentru a instala o astfel de ansamblu în GAC, trebuie să dezactivați sistemul pentru a verifica integritatea fișierelor de asamblare sunând utilitarul SN.exe cu opțiunea de linie de comandă -Vr. Apelarea SN.exe cu acest parametru obligă de asemenea CLR să ignore verificarea valorii hash pentru toate fișierele de asamblare atunci când este încărcată la timpul de execuție. Din punct de vedere al mecanismelor interne ale sistemului, setarea -Vr utilitate SN.exe oferă cazare informații de identificare de asamblare în diferite registru de afaceri HKEY_LOCAL_ UTILAJ \ SOFTWARE \ Microsoft \ StrongName \ de verificare.

Notă. Când utilizați orice utilitar care are acces la registru, trebuie să vă asigurați că un utilitar pe 64 de biți este utilizat pentru platforma pe 64 de biți. În mod implicit utilitatea pentru platforma x86 pe 32 de biți este instalat în directorul C: \ Program Files (x86) Microsoft SDK-uri \ Windows \ v7.0A \ bi n \ NETFX 4.0 Instrumente și utilitatea pentru 64-bit x64-platformă în C \: \ Program Files (x86) \ SDK-uri Microsoft \ Windows \ v7.0A \ b în \ NETFX 4.0 Tools \ x64.

Ansamblul testat în cele din urmă trebuie să fie semnat oficial pentru a putea fi împachetat și implementat. Pentru a semna ansamblul, sunați din nou utilitarul SN.exe, dar de data aceasta cu opțiunea -R, specificând numele fișierului care conține cheia privată curentă. Opțiunea -R determină SN.exe să calculeze conținutul fișierului, să semneze cu o cheie privată și să încorporeze semnătura digitală RSA în spațiul liber rezervat. După aceea, ansamblul, semnat de toate regulile, este pregătit pentru desfășurare. De asemenea, puteți anula verificarea asamblării apelând SN.exe cu opțiunea -Vu sau -Vx.

Secvența completă a acțiunilor pentru crearea unui ansamblu cu semnătură amânată este după cum urmează.

1. În timpul desfășurării ansamblului, trebuie să obțineți un fișier care conține numai cheia publică a companiei și să adăugați parametrii / keyfile și / delaysign la linia de compilare a ansamblului:

2. După asamblarea ansamblului, trebuie să executați următoarea comandă pentru a testa acest ansamblu, ao instala în directorul GAC și pentru a construi alte ansambluri care îl referă. Trebuie doar să executați această comandă o singură dată, nu trebuie să faceți acest lucru de fiecare dată când construiți o adunare.

3. Pregătiți-vă să împachetați și să implementați ansamblul, trebuie să obțineți cheia publică a companiei și să executați următoarea comandă. Dacă doriți, puteți instala o nouă versiune a GAC, dar nu încercați să faceți acest lucru până când nu faceți pasul 4.

4. Pentru a testa asamblarea în condiții reale, pentru a executa din nou testul, executați următoarea comandă:

Dacă perechea de chei este stocată în container SSR, este necesar să se utilizeze și alte opțiuni la accesarea utilități CSC.exe, AL.exe și SN.exe. Când compilarea (CSC.exe) în loc de / keyfile este necesar să se utilizeze parametrul / keycontainer, atunci când conectarea (AL.exe) - parametru / KeyName loc / keyfile, în timp ce SN.exe apel pentru a adăuga cheia privată a ansamblului, care a fost amânată semnarea - parametru -Re în loc de -R. SN.exe acceptă parametri suplimentari pentru lucrul cu CSP.

Notă. Este convenabil să amânați semnarea când trebuie să efectuați anumite acțiuni pe ansamblu înainte de a fi implementată. De exemplu, este posibil să doriți să aplicați utilitare de securitate ansamblului care modifică codul dincolo de recunoaștere. După ce ansamblul este semnat, acest lucru nu poate fi făcut, deoarece hash-ul va deveni invalid. Deci, dacă aveți nevoie să îl protejați de decompilare sau să efectuați alte acțiuni asupra acestuia după asamblarea construirii, trebuie să aplicați tehnica de semnătură amânată. În final, trebuie să executați utilitarul SN.exe cu opțiunea -R sau -Re pentru a finaliza asamblarea și a calcula toate valorile hash necesare.







Articole similare

Pagina anterioară

Pagina următoare

Trimiteți-le prietenilor: