Assemblies – základní kámen aplikace v .NET

.NET framework přichází s novým pojetím výsledného modulu aplikace a nazývá ho „assembly“. Jde o sestavu jednoho nebo více exe, dll, .module souborů, zdrojů a manifestu. Assembly je tedy jakási základní programová část, ze které se programy sestávají a která zprostředkovává řízení verzí a bezpečnosti.

Proč vlastně zavádět assembly?

Důležitá je samostatnost aplikací – např. nezávislost na registrech, COM+ katalozích atd. Odpadají pak problémy s instalací a odinstalací. Pomocí assembly také dochází k přesnému řízení verzí aplikací a jejich knihoven. Ty jsou kontrolovány při spuštění aplikace. Cílem je odstranit DLL hell (viz níže). .NET framework musí také zajistit, aby aplikace byla kompletně izolovaná a nebyla ovlivněná jakýmikoli zásahy do počítače(instalace/odinstalace jiných aplikací, které třeba instalují stejné knihovny jako používá vaše aplikace). Dále musí assembly obsahovat informace o „veřejných typech“. Jelikož provázanost jazyků je jeden z nejdůležitějších rysů .NET frameworku a každá assembly vytváří své vlastní typy, tak je na tento bod kladen velký důraz. Problém se řeší pomocí mechanismu metadat.

Metadata jsou tedy uložena v assembly a obsahují :

• Odkazy na další assembly. Každá aplikace využívá jiné knihovny, minimálně systémové knihovny a tedy potřebuje mít zapsáno jaké knihovny používá a s jakými verzemi, aby se zabránilo potenciálním problémům.
• Seznam souborů. Manifest obsahuje jména všech souborů, které tvoří assembly. Dále je v manifestu uložen ještě hash klíč obsahu každého z těchto souborů, aby se zabránilo v úmyslnému poškození souboru.
• Identitu. Ta se skládá z jména, čísla verze a případně kultury.
• Exportované typy a zdroje. Definice typů deklarovaných jako veřejné, které jsou využívatelné jinými assemblies. Také zdroje jsou deklarovatelné jako veřejné a tedy z jiných assemblies viditelné.

Assemblies tedy obsahují assembly metadata, typová metadata MSIL kódu a reference a MSIL kód zdroje.

Instalace assemblies

Assemblies s sebou nesou nový typ instalace aplikací. Doposud se instalace aplikace sestávala z fyzického kopírování souborů a vytváření dodatečných záznamů v registrech a COM+ katalozích. To bylo nutné odstranit z instalačního procesu, aby byla zachována izolovanost aplikací a přitom se výrazně změnil proces instalace aplikací. Právě část manifestu nese tyto dodatečné informace nutné pro běh aplikace.

Assemblies se z hlediska instalace dělí na dva druhy.  Soukromé aplikační assembly, jsou vhodné pouze pro danou konkrétní úlohu ke konkrétnímu programu, jsou tedy naprosto izolované a tedy privátní. Oproti tomu jejich sdílená varianta, ač vnitřně úplně shodná, je instalována mimo aplikační adresář a jsou na ni kladeny vyšší nároky, co se verzování týče.

Soukroumé assembly

Tato assembly by se dala přirovnat k obyčejné DLL knihově jakékoli firmy, která si ji vytvořila pouze pro své interní použití a nepočítala s nějakým masovějším rozšířením kódu této knihovny do ostatních aplikací. Instaluje se vždy do stejného adresáře jako program, ke kterému náleží a nikdy ne do složek Windows, nebo Windows\System32. Takové knihovny musí být samozřejmě jedinečné pouze v rámci aplikace. Z toho plynou výhody, že instalace celé aplikace se zmenší na úkon XCOPY. Nezískají se tím samozřejmě výhody typu zástupců na pracovní ploše nebo v nabídce Start, ale aplikace je takto přenositelná a tedy i funkční.

Sdílené assembly

Druhý typ se dá přirovnat k DLL souboru tzv. od programátora – programátorovi. Jsou to knihovny, které jedna firma vyvíjí proto, aby ostatní mohli tento kód požívat ve svých aplikacích. Typickými představiteli těchto assemblies jsou základní assemblies instalované s .NET frameworkem. Přinášejí výhody sdíleného kódu a tedy menšího množství zabraného místa na disku (představte si případ, že by každá .NET aplikace měla ve svém aplikačním adresáři uložený celý 20MB .NET framework). Přinášejí ale také strasti spojené s jejich verzováním a pojmenováním.

Pojmenování assembly je složitější problém, protože výskyt dvou různých assemblies se stejným jménem je poněkud nezáviděníhodná situace. Stejné problémy mohou nastat při problému nazvaném již dlouho DLL hell. Např. máte aplikaci A, která používá knihovnu KNIHOVNA  verze 1.0. Nainstalujete si další aplikaci třeba B, která také využívá knihovnu KNIHOVNA, ale již ve verzi 2.0. Instalátor někdy se souhlasem, někdy bez, nahradí knihovnu novější verzí. V lepším případě může všechno pracovat v  pořádku a aplikace havaruje třeba až za pár měsíců, kdy se dostane k funkci v knihovně, která je třeba málo využívaná a autor u ní v nové verzi změnil počet parametrů. V tom horším případě, pokud byl změněn kód frekventovaně využívaný, bude aplikace dělat problémy často, nebo nepůjde vůbec spustit.

Řešení s pomocí assembly má několik kroků. Nejdříve musíme assembly pojmenovat názvem jedinečným a nenapodobitelným jiným autorem. Dále musí být assembly nainstalována do speciálního adresáře GAC (Global Assembly Cache), kde se shromaždují všechny veřejné assembly. Tento adresář je fyzicky na disku reprezentován adresářem „assembly“ u systému Windows 9x a ME ve složce Windows a systémů NT, 2k, XP ve složce WinNT.

Výhodami GAC jsou souborová bezpečnost (práce s GAC je povolena pouze administrátoru systému) a existence více verzí (v GAC můžete uchovávat na jednom místě více verzí jedné komponenty stejného jména).

Nejednodušší nástroj na administraci GAC je Průzkumník. Skládá určení assembly v GAC z jejího jména, verze, a veřejného klíče token. Práce s GAC v Průzkumníku je stejná, jako práce s ostatními soubory.

Tak jako na jakýkoli soubor na disku, můžete i na assemblies v GAC klepnout pravým tlačítkem a zobrazit si jak veškeré informace o ní (jako u běžných DLL souborů), tak i rozšířené parametry, které jsem již zmínil.