Zjednodušení nasazení a řešení problémů s knihovnou DLL s využitím rozhraní .NET Framework

Článek
04/05/2007

Steven Pratschner
Microsoft Corporation

Aktualizováno v listopadu 2001

Shrnutí: Tento článek představuje koncept sestavení a popisuje, jak rozhraní .NET Framework používá sestavení k řešení problémů se správou verzí a nasazením. (16 vytištěných stránek)

Obsah

Úvod
Popis problému
Charakteristiky řešení
Sestavení: Stavební bloky
Správa verzí a sdílení
Zásady verzí
Nasazení
Souhrn

Úvod

Rozhraní Microsoft® .NET Framework zavádí několik nových funkcí, jejichž cílem je zjednodušit nasazení aplikací a řešit peklo dll. Koncoví uživatelé i vývojáři jsou obeznámeni s problémy se správou verzí a nasazením, které můžou vzniknout u dnešních systémů založených na komponentách. Například prakticky každý koncový uživatel si na svůj počítač nainstaloval novou aplikaci, aby zjistil, že existující aplikace záhadně přestane fungovat. Většina vývojářů také strávila čas s programem Regedit a snažila se zachovat všechny potřebné položky registru konzistentní, aby bylo možné aktivovat třídu MODELU COM.

Pokyny k návrhu a techniky implementace používané v rozhraní .NET Framework k řešení DLL Hell jsou založeny na práci provedené v systému Microsoft Windows® 2000, jak popisuje Rick Anderson v článku Konec dll pekla a David D'Souza, BJ Whalen a Peter Wilson v implementaci souběžného sdílení komponent v aplikacích (expanded). Rozhraní .NET Framework rozšiřuje tuto předchozí práci tím, že poskytuje funkce, včetně izolace aplikací a souběžných komponent pro aplikace vytvořené pomocí spravovaného kódu na platformě .NET. Všimněte si také, že systém Windows XP poskytuje stejné funkce izolace a správy verzí pro nespravovaný kód, včetně tříd COM a knihoven DLL Win32 (podrobnosti najdete v tématu Jak vytvářet a obsluhovat izolované aplikace a souběžná sestavení pro Systém Windows XP ).

Tento článek představuje koncept sestavení a popisuje, jak rozhraní .NET používá sestavení k řešení problémů se správou verzí a nasazením. Konkrétně probereme, jak jsou sestavení strukturovaná, jak jsou pojmenována a jak kompilátory a modul CLR (Common Language Runtime) používají sestavení k zaznamenávání a vynucování závislostí verzí mezi částmi aplikace. Probereme také, jak můžou aplikace a správci přizpůsobit chování správy verzí prostřednictvím toho, čemu říkáme zásady verzí.

Po zavedení a popisu sestavení se zobrazí několik scénářů nasazení, které poskytují vzorkování různých možností balení a distribuce dostupných v rozhraní .NET Framework.

Popis problému

Správa verzí

Z pohledu zákazníka je nejběžnějším problémem se správou verzí to, čemu říkáme DLL Hell. Jednoduše řečeno, DLL Hell odkazuje na sadu problémů způsobených, když se více aplikací pokusí sdílet společnou komponentu, jako je dynamická knihovna (DLL) nebo třída modelu COM (Component Object Model). V nejtypičtějším případě jedna aplikace nainstaluje novou verzi sdílené komponenty, která není zpětně kompatibilní s verzí, která už je na počítači. I když aplikace, která byla právě nainstalována, funguje správně, stávající aplikace, které závisely na předchozí verzi sdílené komponenty, už nemusí fungovat. V některých případech je příčina problému ještě jemnější. Představte si například scénář, kdy uživatel stáhne ovládací prvek Microsoft ActiveX® jako vedlejší efekt při návštěvě některého webu. Po stažení ovládacího prvku nahradí všechny existující verze ovládacího prvku, které byly na počítači. Pokud se stane, že tento ovládací prvek použije aplikace nainstalovaná na počítači, může také potenciálně přestat fungovat.

V mnoha případech dochází k významnému zpoždění, než uživatel zjistí, že aplikace přestala fungovat. V důsledku toho je často obtížné si vzpomenout, kdy byla v počítači provedena změna, která mohla mít vliv na aplikaci. Uživatel si může vzpomenout, že něco nainstaloval před týdnem, ale neexistuje žádná zjevná korelace mezi instalací a chováním, které teď vidí. Aby to bylo ještě horší, je dnes k dispozici několik diagnostických nástrojů, které uživateli (nebo pracovníkovi podpory, který jim pomáhá) určit, co je špatně.

Důvodem těchto problémů je, že systém nezaznamená nebo nevynucuje informace o verzích různých komponent aplikace. Změny provedené v systému jménem jedné aplikace také obvykle ovlivní všechny aplikace na počítači – sestavení aplikace, která je v současnosti zcela izolovaná od změn, není snadné.

Jedním z důvodů, proč je obtížné vytvořit izolovanou aplikaci, je to, že aktuální prostředí za běhu obvykle umožňuje instalaci pouze jedné verze komponenty nebo aplikace. Toto omezení znamená, že autoři komponent musí psát svůj kód způsobem, který zůstává zpětně kompatibilní, jinak riskují, že při instalaci nové komponenty dojde k narušení stávajících aplikací. V praxi je psaní kódu, který je navždy zpětně kompatibilní, velmi obtížné, ne-li nemožné. V .NET je v textu správy verzí základní pojem vedle sebe . Vedle sebe je možnost nainstalovat a spustit na počítači současně několik verzí stejné komponenty. S komponentami, které podporují vedle sebe, nejsou autoři nutně vázáni na zachování přísné zpětné kompatibility, protože různé aplikace mohou používat různé verze sdílené komponenty.

Nasazení a instalace

Instalace aplikace dnes je vícekrokový proces. Instalace aplikace obvykle zahrnuje zkopírování řady softwarových komponent na disk a vytvoření řady položek registru, které popisují tyto součásti systému.

Oddělení položek v registru a souborů na disku velmi ztěžuje replikaci aplikací a jejich odinstalaci. Také vztah mezi různými položkami potřebnými k úplnému popisu třídy COM v registru je velmi volný. Tyto položky často zahrnují položky pro coclasses, interfaces, typelibs a ID aplikací DCOM, nemluvě o žádných položkách provedených pro registraci rozšíření dokumentů nebo kategorií součástí. Často se stává, že je budete synchronizovat ručně.

A konečně, tato stopa registru je vyžadována k aktivaci jakékoli třídy COM. To výrazně komplikuje proces nasazení distribuovaných aplikací, protože každý klientský počítač se musí dotknout, aby se příslušné položky registru udělaly.

Tyto problémy jsou způsobeny především popisem komponenty, která je oddělena od samotné komponenty. Jinými slovy, aplikace nejsou ani samostatně popisující, ani samostatné.

Charakteristiky řešení

Rozhraní .NET Framework musí poskytovat následující základní funkce pro řešení právě popsaných problémů:

Aplikace musí být popisující sami. Aplikace, které samy popisují, odeberou závislost na registru, umožňují instalaci s nulovým dopadem a zjednodušují odinstalaci a replikaci.
Informace o verzi se musí zaznamenávat a vynucovat. Podpora správy verzí musí být integrovaná do platformy, aby se zajistilo, že se za běhu načte správná verze závislosti.
Musí si vzpomenout na "poslední známé dobro". Když se aplikace úspěšně spustí, musí si platforma pamatovat sadu komponent (včetně jejich verzí), které spolupracovaly. Kromě toho musí být k dispozici nástroje, které správcům umožní snadno vrátit aplikace do tohoto "posledního známého dobrého" stavu.
Podpora souběžných komponent Když povolíte, aby se na počítači současně nainstalovalo a spustilo několik verzí komponenty, umožňuje volajícím určit, jakou verzi by chtěli načíst místo verze vynucené pro nevědomky. Rozhraní .NET Framework jde vedle sebe o krok dál tím, že umožňuje, aby na jednom počítači souběžně existovat více verzí samotné architektury. To výrazně zjednodušuje scénář upgradu, protože správce může v případě potřeby spouštět různé aplikace v různých verzích rozhraní .NET Framework.
Izolace aplikace. Rozhraní .NET Framework musí usnadnit, a ve skutečnosti jako výchozí, psát aplikace, které nemohou být ovlivněny změnami provedenými v počítači jménem jiných aplikací.

Sestavení: Stavební bloky

Sestavení jsou stavební bloky používané rozhraním .NET Framework k řešení právě popsaných problémů se správou verzí a nasazením. Sestavení jsou jednotkou nasazení pro typy a prostředky. V mnoha ohledech sestavení odpovídá knihovně DLL v dnešním světě; sestavení jsou v podstatě "logické knihovny DLL".

Sestavení se popisují prostřednictvím metadat označovaných jako manifest. Stejně jako rozhraní .NET používá metadata k popisu typů, používá také metadata k popisu sestavení, která obsahují typy.

Sestavení jsou mnohem více než nasazení. Například správa verzí v .NET se provádí na úrovni sestavení – není ve verzích nic menšího, jako je modul nebo typ. Sestavení se také používají ke sdílení kódu mezi aplikacemi. Sestavení, ve které je typ obsažen, je součástí identity typu.

Systém zabezpečení přístupu kódu používá sestavení v jádru svého modelu oprávnění. Autor sestavení zaznamená v manifestu sadu oprávnění potřebných ke spuštění kódu a správce udělí oprávnění ke kódu na základě sestavení, ve kterém je kód obsažen.

Sestavení jsou také jádrem systému typů a systému běhu v tom, že vytvářejí hranici viditelnosti pro typy a slouží jako rozsah běhu pro překlad odkazů na typy.

Manifesty sestavení

Konkrétně manifest obsahuje následující data o sestavení:

Identity. Identita sestavení se skládá ze čtyř částí: jednoduchého názvu textu, čísla verze, volitelné jazykové verze a volitelného veřejného klíče, pokud bylo sestavení sestaveno pro sdílení (viz část o sdílených sestaveních níže).
Seznam souborů. Manifest obsahuje seznam všech souborů, které tvoří sestavení. Pro každý soubor manifest zaznamenává svůj název a kryptografickou hodnotu hash jeho obsahu v době sestavení manifestu. Tato hodnota hash se ověřuje za běhu, aby se zajistilo, že je jednotka nasazení konzistentní.
Odkazovaná sestavení. Závislosti mezi sestaveními jsou uloženy v manifestu volajícího sestavení. Informace o závislostech zahrnují číslo verze, které se používá za běhu k zajištění načtení správné verze závislosti.
Exportované typy a prostředky Možnosti viditelnosti dostupné pro typy a prostředky zahrnují možnost "viditelné pouze v rámci sestavení" a "viditelné pro volající mimo sestavení".
Žádosti o oprávnění. Žádosti o oprávnění pro sestavení jsou seskupené do tří sad: 1) ty, které se vyžadují ke spuštění sestavení, 2) ty, které jsou požadovány, ale sestavení bude mít i nadále určité funkce, i když nebudou uděleny, a 3) ty, které autor nikdy nechce, aby sestavení bylo uděleno.

Nástroj IL Disassembler (Ildasm) SDK je užitečný pro zobrazení kódu a metadat v sestavení. Obrázek 1 je příklad manifestu, který zobrazuje Ildasm. Direktiva .assembly identifikuje sestavení a direktivy .assembly extern obsahují informace o jiných sestaveních, na kterých tato sestavení závisí.

Obrázek 1: Příklad manifestu zobrazeného nástrojem IL Disassembler

Struktura sestavení

Sestavení byla dosud popisována především jako logický koncept. Tato část pomáhá usnadnit konkrétní sestavení tím, že popisuje, jak jsou fyzicky reprezentována.

Obecně se sestavení skládají ze čtyř prvků: metadat sestavení (manifest), metadata popisující typy, kód zprostředkujícího jazyka (IL), který implementuje typy, a sadu prostředků. Ne všechna tato sestavení jsou obsažena v každém sestavení. Pouze manifest je přísně vyžadován, ale k poskytnutí smysluplné funkce sestavení jsou zapotřebí buď typy, nebo prostředky.

Existuje několik možností, jak tyto čtyři prvky "zabalit". Například obrázek 2 znázorňuje jednu knihovnu DLL, která obsahuje celé sestavení: manifest, metadata typu, kód IL a prostředky.

Obrázek 2. Knihovna DLL obsahující všechny prvky sestavení

Případně může být obsah sestavení rozložen do více souborů. Na obrázku 3 se autor rozhodl oddělit určitý kód nástroje do jiné knihovny DLL a zachovat velký soubor prostředků (v tomto případě JPEG) v původním souboru. Jedním z důvodů, proč to může být provedeno, je optimalizace stahování kódu. Rozhraní .NET Framework stáhne soubor pouze v případě, že je na něj odkazováno, takže pokud sestavení obsahuje kód nebo prostředky, ke kterým se přistupuje zřídka, rozdělení do jednotlivých souborů zvýší efektivitu stahování. Dalším běžným scénářem, ve kterém se používá více souborů, je sestavení sestavení, které se skládá z kódu z více než jednoho jazyka. V tomto případě byste sestavili každý soubor (modul) samostatně a pak je seskupili do sestavení pomocí nástroje Assembly Linker, který je součástí sady .NET Framework SDK (al.exe).

Obrázek 3: Prvky sestavení rozložené do více souborů

Jednou z hlavních příčin dll pekla je model sdílení, který se aktuálně používá v systémech založených na komponentách. Ve výchozím nastavení jsou jednotlivé softwarové komponenty sdíleny více aplikacemi na počítači. Například pokaždé, když instalační program zkopíruje knihovnu DLL do systémového adresáře nebo zaregistruje třídu v registru COM, bude mít tento kód potenciálně vliv na jiné aplikace spuštěné v počítači. Konkrétně platí, že pokud existující aplikace používala předchozí verzi této sdílené komponenty, začne tato aplikace automaticky používat novou verzi. Pokud je sdílená komponenta striktně zpětně kompatibilní, může to být v pořádku, ale v mnoha případech je zachování zpětné kompatibility obtížné, ne-li nemožné. Pokud zpětná kompatibilita není zachována nebo ji nelze zachovat, často to vede k porušení aplikací, které jsou vedlejším účinkem instalace jiných aplikací.

Hlavní zásadou návrhu v rozhraní .NET je použití izolovaných komponent (nebo sestavení). Izolování sestavení znamená, že k sestavení může přistupovat pouze jedna aplikace – není sdíleno více aplikacemi na počítači a nemůže být ovlivněno změnami systému provedenými jinými aplikacemi. Izolace dává vývojáři absolutní kontrolu nad kódem, který používá jeho aplikace. Izolovaná nebo soukromá sestavení aplikace jsou výchozím nastavením v aplikacích .NET. Trend směrem k izolovaným komponentám začal v systému Microsoft Windows 2000 se zavedením souboru .local. Tento soubor byl použit k tomu, aby se zavaděč operačního systému i objekt COM při pokusu o vyhledání požadované komponenty nejprve podívali do adresáře aplikace. (Podívejte se na související článek v knihovně MSDN Implementace souběžného sdílení komponent v aplikacích.)

Existují však případy, kdy sdílení sestavení mezi aplikacemi je nezbytné. Je zřejmé, že nedává smysl, aby každá aplikace nesla vlastní kopii System.Windowns.Forms, System.Web nebo běžného Web Forms ovládacího prvku.

V .NET je sdílení kódu mezi aplikacemi explicitním rozhodnutím. Sestavení, která jsou sdílena, mají některé další požadavky. Konkrétně by sdílená sestavení měla být podporována vedle sebe, aby bylo možné nainstalovat a spustit více verzí stejného sestavení na stejném počítači nebo dokonce v rámci stejného procesu ve stejnou dobu. Kromě toho mají sdílená sestavení přísnější požadavky na pojmenování. Například sestavení, které je sdíleno, musí mít název, který je globálně jedinečný.

Potřeba izolace a sdílení nás vede k tomu, abychom si vymysleli dva "druhy" sestavení. Jedná se o poměrně volnou kategorizaci v tom, že mezi nimi nejsou žádné skutečné strukturální rozdíly, ale rozdíl je spíše v tom, jak se budou používat: ať už jsou soukromé pro jednu aplikaci, nebo sdílené mezi mnoha.

Application-Private sestavení

Soukromé sestavení aplikace je sestavení, které je viditelné pouze pro jednu aplikaci. Očekáváme, že se jedná o nejběžnější případ v .NET. Požadavky na pojmenování pro soukromá sestavení jsou jednoduché: Názvy sestavení musí být jedinečné pouze v rámci aplikace. Globálně jedinečný název není potřeba. Zachování jedinečných názvů není problém, protože vývojář aplikace má úplnou kontrolu nad tím, která sestavení jsou izolovaná pro aplikaci.

Soukromá sestavení aplikace jsou nasazena v adresářové struktuře aplikace, ve které se používají. Soukromá sestavení mohou být umístěna přímo do adresáře aplikace nebo do jejich podadresáře. CLR najde tato sestavení prostřednictvím procesu označovaného jako sondování. Sondování je jednoduše mapování názvu sestavení na název souboru, který obsahuje manifest.

Modul CLR konkrétně převezme název sestavení zaznamenaný v odkazu na sestavení, připojí ".dll" a vyhledá tento soubor v adresáři aplikace. V tomto schématu existuje několik variant, kdy bude modul runtime hledat v podadresářích pojmenovaných sestavením nebo v podadresářích pojmenovaných jazykovou verzí sestavení. Vývojář se například může rozhodnout nasadit sestavení obsahující prostředky lokalizované do němčiny v podadresáři s názvem "de" a do španělštiny v adresáři s názvem "es". (Podrobnosti najdete v příručce k sadě .NET Framework SDK.)

Jak jsme právě popsali, každý manifest sestavení obsahuje informace o verzi o svých závislostech. Tyto informace o verzi nejsou vynuceny pro soukromá sestavení, protože vývojář má úplnou kontrolu nad sestaveními, která jsou nasazena do adresáře aplikace.

Sdílená sestavení

Rozhraní .NET Framework podporuje také koncept sdíleného sestavení. Sdílené sestavení je sestavení, které je používáno více aplikacemi na počítači. U .NET je sdílení kódu mezi aplikacemi explicitním rozhodnutím. Sdílená sestavení mají některé další požadavky zaměřené na to, aby se zabránilo problémům se sdílením, se kterými se dnes setkáme. Kromě podpory pro souběžný popis dříve mají sdílená sestavení mnohem přísnější požadavky na pojmenování. Například sdílené sestavení musí mít název, který je globálně jedinečný. Systém musí také zajistit "ochranu názvu", tj. zabránit tomu, aby někdo znovu nepoužádá název sestavení jiného uživatele. Řekněme například, že jste dodavatelem ovládacího prvku mřížky a vydali jste verzi 1 sestavení. Jako autor potřebujete jistotu, že nikdo jiný nemůže uvolnit sestavení, které tvrdí, že je verzí 2 nebo vaším ovládacím prvku mřížky. Rozhraní .NET Framework podporuje tyto požadavky na pojmenování prostřednictvím techniky označované jako silné názvy (podrobně popsané v další části).

Autor aplikace obvykle nemá stejný stupeň kontroly nad sdílenými sestaveními používanými aplikací. V důsledku toho jsou informace o verzi kontrolovány u každého odkazu na sdílené sestavení. Kromě toho rozhraní .NET Framework umožňuje aplikacím a správcům přepsat verzi sestavení, která se používá aplikací, zadáním zásad verze.

Sdílená sestavení nemusí být nutně nasazena soukromě do jedné aplikace, i když je tento přístup stále realizovatelný, zejména pokud je nasazení xcopy povinné. Kromě soukromého adresáře aplikace může být sdílené sestavení nasazeno také do globální mezipaměti sestavení (GAM) nebo do jakékoli adresy URL, pokud je v konfiguračním souboru aplikace zadán základ kódu popisující umístění sestavení. Globální mezipaměť sestavení je úložiště pro sestavení používaná více než jednou aplikací pro celý počítač. Jak je popsáno, nasazení do mezipaměti není povinné, ale má to určité výhody. Například souběžné úložiště více verzí sestavení je poskytováno automaticky. Správci můžou úložiště použít také k nasazení oprav chyb nebo oprav zabezpečení, které mají používat každá aplikace na počítači. Nakonec existuje několik vylepšení výkonu spojených s nasazením do globální mezipaměti sestavení (GPA). První zahrnuje ověření podpisů silných jmen, jak je popsáno v části Silné jméno níže. Druhé zlepšení výkonu zahrnuje pracovní sadu. Pokud několik aplikací používá stejné sestavení současně, načtení sestavení ze stejného umístění na disku využívá chování sdílení kódu poskytované operačním systémem. Naproti tomu načtení stejného sestavení z více různých umístění (adresářů aplikací) způsobí načtení mnoha kopií stejného kódu. Přidání sestavení do mezipaměti na počítači koncového uživatele se obvykle provádí pomocí instalačního programu založeného na Instalační službě systému Windows nebo jiné instalační technologii. Sestavení nikdy neskončí v mezipaměti jako vedlejší efekt spuštění některé aplikace nebo přechodu na webovou stránku. Místo toho instalace sestavení do mezipaměti vyžaduje explicitní akci ze strany uživatele. Instalační služba systému Windows 2.0, která se dodává se systémy Windows XP a Visual Studio .NET, byla vylepšena tak, aby plně porozuměla konceptu sestavení, mezipaměti sestavení a izolovaných aplikací. To znamená, že s aplikacemi .NET budete moct používat všechny funkce Instalační služby systému Windows, jako je instalace na vyžádání a oprava aplikací.

Často není praktické vytvořit instalační balíček pokaždé, když chcete přidat sestavení do mezipaměti na vývojových a testovacích počítačích. V důsledku toho sada .NET SDK obsahuje některé nástroje pro práci s mezipamětí sestavení. První je nástroj s názvem gacutil, který umožňuje přidat sestavení do mezipaměti a později je odebrat. Pomocí přepínače /i přidejte sestavení do mezipaměti:

gacutil /i:myassembly.dll 
See the .NET Framework SDK documentation for a full description of the 
      options supported by gacutil.

Další nástroje jsou rozšíření prostředí systému Windows, které umožňuje manipulovat s mezipamětí pomocí Průzkumníka Windows a konfiguračního nástroje rozhraní .NET Framework. Rozšíření prostředí je přístupné tak, že přejdete do podadresáře "assembly" v adresáři windows. Konfigurační nástroj rozhraní .NET Framework najdete v části Nástroje pro správu Ovládací panely.

Obrázek 4 ukazuje zobrazení globální mezipaměti sestavení pomocí rozšíření prostředí.

Obrázek 4. Globální mezipaměť sestavení

Silné názvy

Silné názvy se používají k povolení přísnějších požadavků na pojmenování spojených se sdílenými sestaveními. Silní jména mají tři cíle:

Jedinečnost názvu. Sdílená sestavení musí mít globálně jedinečné názvy.
Zabraňte falšování názvů. Vývojáři nechtějí, aby někdo jiný vydal následující verzi některého z vašich sestavení a falešně tvrdí, že pochází od vás, ať už omylem nebo úmyslně.
Zadejte identitu na základě odkazu. Při překladu odkazu na sestavení se silné názvy používají k zajištění, že načtené sestavení pochází od očekávaného vydavatele.

Silné názvy se implementují pomocí standardní kryptografie s veřejným klíčem. Obecně proces funguje takto: Autor sestavení vygeneruje pár klíčů (nebo použije existující), podepíše soubor obsahující manifest privátním klíčem a zpřístupní veřejný klíč volajícím. Při odkazování na sestavení volající zaznamená veřejný klíč odpovídající privátnímu klíči použitému ke generování silného názvu. Obrázek 5 popisuje, jak tento proces funguje v době vývoje, včetně toho, jak jsou klíče uloženy v metadatech a jak se generuje podpis.

Scénář je sestavení s názvem "Main", které odkazuje na sestavení s názvem "MyLib". MyLib má sdílený název. Důležité kroky jsou popsány následovně.

Obrázek 5. Proces implementace sdílených názvů

Vývojář vyvolá kompilátor, který předává pár klíčů a sadu zdrojových souborů pro sestavení. Pár klíčů se vygeneruje pomocí nástroje sdk s názvem SN. Například následující příkaz vygeneruje nový pár klíčů a uloží ho do souboru:
```
Sn –k MyKey.snk
The key pair is passed to the compiler using the custom attribute 
        System.Reflection.AssemblyKeyFileAttribute as follows:

   <assembly:AssemblyKeyFileAttribute("TestKey.snk")>
```
Když kompilátor vygeneruje sestavení, veřejný klíč se zaznamená v manifestu jako součást identity sestavení. Zahrnutí veřejného klíče jako součásti identity dává sestavení globálně jedinečný název.
Po vygenerování sestavení je soubor obsahující manifest podepsán privátním klíčem. Výsledný podpis je uložen v souboru .
Když kompilátor vygeneruje main, veřejný klíč myLib se uloží v manifestu main jako součást odkazu na MyLib.

Za běhu rozhraní .NET Framework provádí dva kroky, aby zajistil, že silné názvy poskytují vývojáři požadované výhody. Za prvé, podpis silného názvu myLib je ověřen pouze v případě, že sestavení je nainstalováno do globální mezipaměti sestavení –podpis se znovu neověří, když je soubor načten aplikací. Pokud sdílené sestavení není nasazeno do globální mezipaměti sestavení (GPA), podpis se ověří při každém načtení souboru. Ověření podpisu zajistí, že obsah mylib nebyl od sestavení sestavení změněn. Druhým krokem je ověření, že veřejný klíč uložený jako součást odkazu mainu na myLib odpovídá veřejnému klíči, který je součástí identity myLib. Pokud jsou tyto klíče identické, může si autor aplikace Main být jistý, že verze mylib, která byla načtena, pochází od stejného vydavatele, který vytvořil verzi mylib, se kterou byla sestavena aplikace Main. Tato kontrola rovnocennosti klíčů se provádí za běhu, kdy se přeloží odkaz z main na MyLib.

Termín "podepisování" často přivádí microsoft Authenticode® k mysli. Je důležité si uvědomit, že silné názvy a authenticode nejsou nijak spojené. Tyto dvě techniky mají různé cíle. Konkrétně authenticode znamená úroveň důvěryhodnosti přidruženou k vydavateli, zatímco silné názvy ne. K silným názvům nejsou přidružené žádné certifikáty ani podpisové autority třetích stran. Podepisování silnými názvy také často provádí samotný kompilátor v rámci procesu sestavení.

Dalším aspektem, který stojí za zmínku, je proces odložení podepisování. Často se stává, že autor sestavení nemá přístup k privátnímu klíči potřebnému k úplnému podepsání. Většina společností uchovává tyto klíče v dobře chráněných obchodech, ke kterým má přístup jen několik lidí. V důsledku toho rozhraní .NET Framework poskytuje techniku označovanou jako "pozdržení podepisování", která umožňuje vývojáři sestavit sestavení pouze s veřejným klíčem. V tomto režimu soubor není ve skutečnosti podepsaný, protože není zadaný privátní klíč. Místo toho se soubor později podepíše pomocí nástroje SN. Podrobnosti o použití opožděného podepisování najdete v tématu Pozdržení podepisování sestavení v sadě .NET Framework SDK.

Zásady verzí

Jak jsme právě popsali, každý manifest sestavení zaznamenává informace o verzi každé závislosti, pro které byl sestaven. Existují však některé scénáře, ve kterých autor aplikace nebo správce může chtít spustit za běhu jinou verzi závislosti. Správci by například měli být schopni nasadit verze oprav chyb, aniž by bylo nutné, aby se každá aplikace znovu zkompilovala, aby bylo možné opravu obnovit. Správci také musí být schopni určit, že konkrétní verze sestavení se nikdy nepoužije, pokud je nalezena bezpečnostní díra nebo jiná závažná chyba. Rozhraní .NET Framework umožňuje tuto flexibilitu vazby verzí prostřednictvím zásad verzí.

Čísla verzí sestavení

Každé sestavení má jako součást své identity čtyřdílné číslo verze (to znamená, že verze 1.0.0.0 některého sestavení a verze 2.1.0.2 jsou zcela odlišné identity, pokud jde o zavaděč tříd). Zahrnutí verze jako součásti identity je nezbytné k odlišení různých verzí sestavení pro účely souběžného použití.

Části čísla verze jsou hlavní, podverze, sestavení a revize. U částí čísla verze není použita žádná sémantika. To znamená, že CLR neodvozuje kompatibilitu nebo jiné vlastnosti sestavení na základě způsobu přiřazení čísla verze. Jako vývojář můžete libovolnou část tohoto čísla podle potřeby změnit. I když se na formát čísla verze nepoužívá žádná sémantika, pro jednotlivé organizace bude pravděpodobně užitečné vytvořit konvence týkající se změny čísla verze. To pomáhá udržovat konzistenci v celé organizaci a usnadňuje určení, ze kterého sestavení konkrétního sestavení pochází. Jednou z typických konvencí je následující:

Hlavní nebo vedlejší. Změny hlavní nebo podverze čísla verze značí nekompatibilní změnu. Podle této konvence by se verze 2.0.0.0 považovala za nekompatibilní s verzí 1.0.0.0. Příkladem nekompatibilní změny by byla změna typů některých parametrů metody nebo úplné odebrání typu nebo metody.

Sestavovat. Číslo sestavení se obvykle používá k rozlišení mezi každodenními buildy nebo menšími kompatibilními verzemi.

Revize. Změny čísla revize jsou obvykle vyhrazeny pro přírůstkové sestavení potřebné k opravě konkrétní chyby. Někdy uslyšíte, že se jedná o číslo "nouzové opravy chyb" v tom, že revize se často mění, když se oprava konkrétní chyby expeduje zákazníkovi.

Výchozí zásady verze

Při překladu odkazů na sdílená sestavení clr určuje, která verze závislosti se má načíst, když narazí na odkaz na toto sestavení v kódu. Výchozí zásady verze v .NET jsou velmi jednoduché. Při překladu odkazu clr převezme verzi z manifestu volajícího sestavení a načte verzi závislosti se stejným číslem verze. Tímto způsobem získá volající přesnou verzi, se kterou byl sestaven a testován. Tato výchozí zásada má vlastnost, která chrání aplikace před scénářem, kdy jiná aplikace nainstaluje novou verzi sdíleného sestavení, na které závisí existující aplikace. Vzpomeňte si, že před .NET by existující aplikace začaly používat novou sdílenou komponentu ve výchozím nastavení. V .NET však instalace nové verze sdíleného sestavení nemá vliv na existující aplikace.

Zásady vlastních verzí

Někdy může dojít k tomu, že vazba na přesnou verzi, se kterou byla aplikace dodána, není to, co chcete. Správce může například nasadit důležitou opravu chyby do sdíleného sestavení a chtít, aby tuto novou verzi používaly všechny aplikace bez ohledu na to, s jakou verzí byly vytvořeny. Dodavatel sdíleného sestavení také mohl odeslat servisní verzi do existujícího sestavení a chce, aby všechny aplikace začaly používat verzi služby místo původní verze. Tyto a další scénáře jsou podporované v rozhraní .NET Framework prostřednictvím zásad verzí.

Zásady verzí jsou uvedeny v souborech XML a jsou jednoduše požadavkem na načtení jedné verze sestavení místo jiné. Například následující zásady verzí nasměrují clr k načtení verze 5.0.0.1 namísto verze 5.0.0.0 sestavení s názvem MarineCtrl:

 <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <dependentAssembly
   <assemblyIdentity name="MarineCtrl" publicKeyToken="9335a2124541cfb9" />
      <bindingRedirect oldVersion="5.0.0.0" newVersion="5.0.0.1" />   
  </dependentAssembly>
</assemblyBinding>

Kromě přesměrování z konkrétního čísla verze na jiné můžete také přesměrovat z celé řady verzí na jinou verzi. Následující zásada například přesměruje všechny verze od 0.0.0.0 do 5.0.0.0 MarineCtrl na verzi 5.0.0.1:

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <dependentAssembly
   <assemblyIdentity name="MarineCtrl" publicKeyToken="9335a2124541cfb9" />
      <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.1" />   
  </dependentAssembly>
</assemblyBinding>

Úrovně zásad verze

Existují tři úrovně, na kterých je možné použít zásady verzí v .NET: zásady specifické pro aplikaci, zásady vydavatele a zásady pro celý počítač.

Zásady specifické pro aplikaci. Každá aplikace má volitelný konfigurační soubor, který může určovat přání aplikace vytvořit vazbu na jinou verzi závislého sestavení. Název konfiguračního souboru se liší v závislosti na typu aplikace. U spustitelných souborů je název konfiguračního souboru název spustitelného souboru + přípony .config. Například konfigurační soubor pro "myapp.exe" by byl "myapp.exe.config". Konfigurační soubory pro ASP.NET aplikace jsou vždy "web.config".

Zásady vydavatele. Zatímco zásady specifické pro aplikaci jsou nastaveny vývojářem aplikace nebo správcem, zásady vydavatele jsou nastaveny dodavatelem sdíleného sestavení. Zásady vydavatele jsou prohlášení o kompatibilitě dodavatele týkající se různých verzí sestavení. Řekněme například, že dodavatel sdíleného ovládacího prvku model Windows Forms dodává servisní verzi, která obsahuje řadu oprav chyb ovládacího prvku. Původní ovládací prvek byl verze 2.0.0.0 a verze služby je 2.0.0.1. Vzhledem k tomu, že nová verze obsahuje jenom opravy chyb (žádné změny rozhraní API způsobující chybu), dodavatel ovládacího prvku pravděpodobně vydá zásady vydavatele s novou verzí, která způsobí, že stávající aplikace, které používaly verzi 2.0.0.0.0, teď začnou používat verzi 2.0.0.1. Zásady vydavatele se v JAZYCE XML vyjadřují stejně jako zásady pro celou aplikaci a počítač, ale na rozdíl od těchto ostatních úrovní zásad se zásady vydavatele distribuují jako samotné sestavení. Hlavním důvodem je zajistit, aby organizace, která vydává zásady pro konkrétní sestavení, byla stejná organizace, která vydala samotné sestavení. Toho dosáhnete tak, že se vyžaduje, aby jak původnímu sestavení, tak sestavení zásad bylo přiřazeno silné jméno se stejným párem klíč-pár.

Zásady pro celý počítač. Poslední úrovní zásad jsou zásady pro celý počítač (někdy označované jako zásady správce). Zásady pro celý počítač jsou uložené v machine.config, která se nachází v podadresáři config v instalačním adresáři rozhraní .NET Framework. Instalační adresář je %windir%\microsoft.net\framework\%runtimeversion%. Prohlášení o zásadách provedená v machine.config ovlivňují všechny aplikace spuštěné na počítači. Zásady pro celý počítač používají správci k vynucení použití konkrétní verze sestavení pro všechny aplikace na daném počítači. Nejvíce komentářový scénář, ve kterém se to používá, je, když je do globální mezipaměti sestavení assembly nasazena oprava zabezpečení nebo jiná důležitá oprava chyb. Po nasazení pevného sestavení by správce použil zásady verzí pro celý počítač, aby zajistil, že aplikace nebudou používat starou, nefunkční verzi sestavení.

Vyhodnocení zásad

První věcí, kterou CLR udělá při vazbě na sestavení se silným názvem, je určit, ke které verzi sestavení se má svázat. Proces začíná přečtením čísla verze požadovaného sestavení, které bylo zaznamenáno v manifestu sestavení, na které odkazuje. Zásady se pak vyhodnotí, aby se zjistilo, jestli některá z úrovní zásad obsahuje přesměrování na jinou verzi. Úrovně zásad se vyhodnocují v pořadí počínaje zásadami aplikace, následované vydavatelem a nakonec správcem.

Přesměrování zjištěné na libovolné úrovni přepíše všechny příkazy provedené předchozí úrovní. Řekněme například, že sestavení A odkazuje na sestavení B. Odkaz na B v manifestu A je na verzi 1.0.0.0. Zásady vydavatele dodávané se sestavením B navíc přesměrují odkaz z verze 1.0.0.0 na 2.0.0.0. Kromě toho existuje zásada verze je konfigurační soubor pro celý počítač, který odkazuje na verzi 3.0.0.0. V tomto případě příkaz provedený na úrovni počítače přepíše příkaz provedený na úrovni vydavatele.

Obcházení zásad vydavatele

Vzhledem k pořadí, ve kterém jsou tyto tři typy zásad použity, může přesměrování verze (zásada vydavatele) vydavatele přepsat jak verzi zaznamenanou v metadatech volajícího sestavení, tak všechny zásady specifické pro aplikaci, které byly nastaveny. Vynucení aplikace, aby vždy přijímala doporučení vydavatele o správě verzí, však může vést zpět k pekle knihovny DLL. Koneckonců, DLL Hell je primárně způsobeno obtížností zachování zpětné kompatibility ve sdílených komponentách. Aby se dále zabránilo scénáři, kdy je aplikace poškozena instalací nové verze sdílené komponenty, systém zásad verzí v .NET umožňuje jednotlivým aplikacím obejít zásady vydavatele. Jinými slovy, aplikace může odmítnout doporučení vydavatele o tom, kterou verzi použít. Aplikace může obejít zásady vydavatele pomocí elementu publisherPolicy v konfiguračním souboru aplikace:

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

<publisherPolicy apply="no"/>

</assemblyBinding>

Nastavení zásad verzí pomocí konfiguračního nástroje .NET

Rozhraní .NET Framework se naštěstí dodává s grafickým nástrojem pro správu, takže si nemusíte dělat starosti s ruční úpravou souborů zásad XML. Nástroj podporuje zásady verzí pro aplikaci i pro celý počítač. Nástroj najdete v části Nástroje pro správu Ovládací panely. Počáteční obrazovka nástroje pro správu vypadá takto: Obrázek 6:

Obrázek 6 Nástroj Správa

Následující kroky popisují, jak nastavit zásady specifické pro aplikaci:

Přidejte aplikaci do uzlu Aplikace ve stromovém zobrazení. Klikněte pravým tlačítkem na uzel Aplikace a klikněte na Přidat. V dialogovém okně Přidat se zobrazí seznam aplikací .NET, ze které si můžete vybrat. Pokud vaše aplikace není v seznamu, můžete ji přidat kliknutím na Další.
Zvolte sestavení, pro které chcete nastavit zásady. Klikněte pravým tlačítkem na uzel Nakonfigurovaná sestavení a klikněte na Přidat. Jednou z možností je vybrat sestavení ze seznamu sestavení, na která aplikace odkazuje, a zobrazí se následující dialogové okno, jak je znázorněno na obrázku 7. Vyberte sestavení a klikněte na Vybrat.

Obrázek 7. Volba sestavení
V dialogovém okně Vlastnosti zadejte informace o zásadách verze. Klikněte na kartu Zásady vazby a zadejte do tabulky požadovaná čísla verzí, jak je znázorněno na obrázku 8.

Obrázek 8. Karta Zásady vazby

Nasazení

Nasazení zahrnuje aspoň dva různé aspekty: zabalení kódu a distribuci balíčků do různých klientů a serverů, na kterých bude aplikace běžet. Primárním cílem rozhraní .NET Framework je zjednodušit nasazení (zejména distribuční aspekt) tím, že je možné provést instalaci s nulovým dopadem a nasazení xcopy. Sebepopisující povaha sestavení nám umožňuje odebrat naši závislost na registru, což výrazně zjednodušuje instalaci, odinstalaci a replikaci. Existují však scénáře, kdy xcopy není dostatečný nebo vhodný jako distribuční mechanismus. V těchto případech poskytuje rozhraní .NET Framework rozsáhlé služby pro stahování kódu a integraci s Instalační službou systému Windows.

Zabalení

V první verzi rozhraní .NET Framework jsou k dispozici tři možnosti balení:

Sestavené (knihovny DLL a soubory EXE). V mnoha scénářích se nevyžaduje žádné zvláštní balení. Aplikaci je možné nasadit ve formátu vytvořeném nástrojem pro vývoj. To znamená kolekci knihoven DLL a EXE.
Soubory CAB. Soubory CAB lze použít ke kompresi aplikace pro efektivnější stahování.
Balíčky Instalační služby systému Windows. Microsoft Visual Studio .NET a další instalační nástroje umožňují vytvářet balíčky Instalační služby systému Windows (.msi soubory). Instalační služba systému Windows umožňuje využívat výhody oprav aplikací, instalace na vyžádání a dalších funkcí správy aplikací systému Microsoft Windows.

Scénáře distribuce

Aplikace .NET lze distribuovat různými způsoby, včetně xcopy, stahování kódu a prostřednictvím Instalační služby systému Windows.

U mnoha aplikací, včetně webových aplikací a webových služeb, je nasazení stejně jednoduché jako zkopírování sady souborů na disk a jejich spuštění. Odinstalace a replikace jsou stejně snadné – stačí odstranit soubory nebo je zkopírovat.

Rozhraní .NET Framework poskytuje rozsáhlou podporu stahování kódu pomocí webového prohlížeče. V této oblasti bylo provedeno několik vylepšení, mezi které patří:

Nulový dopad. Na počítači nejsou vytvořené žádné položky registru.
Přírůstkové stahování. Části sestavení se stáhnou pouze při odkazování.
Stáhněte si izolovaně do aplikace. Kód stažený jménem jedné aplikace nemůže ovlivnit ostatní na počítači. Primárním cílem naší podpory stahování kódu je zabránit scénáři, kdy uživatel stáhne novou verzi některé sdílené komponenty jako vedlejší účinek procházení konkrétního webu a má tato nová verze nepříznivý vliv na jiné aplikace.
Žádná dialogová okna Authenticode. Systém zabezpečení přístupu kódu umožňuje spuštění mobilního kódu s částečnou úrovní důvěryhodnosti. Uživatelům se nikdy nezobrazí dialogová okna s výzvou, aby se rozhodli, jestli kódu důvěřují.

Rozhraní .NET je plně integrované s Instalační službou systému Windows a funkcemi pro správu aplikací systému Windows.

Souhrn

Rozhraní .NET Framework umožňuje instalaci s nulovým dopadem a řeší knihovnu DLL Hell. Sestavení jsou samopopisující jednotky nasazení s možnou verzí, které se používají k povolení těchto funkcí.

Schopnost vytvářet izolované aplikace je zásadní, protože umožňuje vytvářet aplikace, které nebudou ovlivněny změnami provedenými v systému jinými aplikacemi. Rozhraní .NET Framework podporuje tento typ aplikace prostřednictvím privátních sestavení aplikace, která jsou nasazena v adresářové struktuře aplikace.

Vedle sebe je základní součástí scénáře sdílení a správy verzí v .NET. Umožňuje souběžnou instalaci a spuštění více verzí sestavení na počítači a umožňuje každé aplikaci požadovat určitou verzi tohoto sestavení.

ClR zaznamenává informace o verzi mezi částmi aplikace a používá je za běhu k zajištění načtení správné verze závislosti. Zásady verzí můžou používat vývojáři aplikací i správci, aby zajistili určitou flexibilitu při výběru verze daného sestavení, která se načte.

Rozhraní .NET Framework poskytuje několik možností balení a distribuce, včetně Instalační služby systému Windows, stažení kódu a jednoduchého nástroje xcopy.

Sdílet prostřednictvím