Część druga 

Streszczenie

Celem artykuły jest zaznajomienie czytelnika z bardziej zaawansowanymi aspektami tworzenia hostów Common Language Runtime. W artykule zostaną wyjaśnione podstawy implementacji własnych  managerów poprzez wykorzystywanie interfejsów managerów hosta, a także wykorzystanie gotowych implementacji managerów CLR dostarczających gotową do użycia funkcjonalność. Zostanie opisana także typowa architektura poprawnie zaprojektowanego hosta wraz z korzyściami jakie ze sobą niesie. Na początku zostanie jednak omówione zagadnienie opóźnionego startu. Nie ma ono bezpośredniego związku z główną tematyką, jednak jego znajomość może stać się nieoceniona podczas pisania własnych programów hostujących silnik wykonawczy platformy Microsoft .NET.

Aby Czytelnik mógł w pełni zrozumieć całość prezentowanego materiału, podstawowa znajomość niezarządzanego API CLR’a jest wymagana. W szczególności, Czytelnik powinien wiedzieć w jaki sposób CLR jest ładowany do pamięci i jak można go załadować z poziomu kodu C++, co oznaczają poszczególne parametry inicjalizacyjne, jak uruchomić i zatrzymać CLR w procesie systemu operacyjnego. Ponadto, podstawowa wiedza dotycząca technologii COM będzie przydatna. Czytelnik niezaznajomiony z opisaną problematyką powinien wcześniej zapoznać się z tekstem części pierwszej tego artykułu dostępnej pod adresem http://codeguru.pl/article-665.aspx.

Wprowadzenie

Firma Microsoft tworząc platformę .NET zaprojektowała ją tak, aby była jak najbardziej rozszerzalna, aby można było dzięki niej tworzyć zarówno klasyczne oprogramowanie użytkowe czy biznesowe, ale także żeby łatwo i wygodnie można było  implementować komponenty złożonych systemów komputerowych, wymagających najwyższej wydajności i niezawodności. W przypadku klasycznych aplikacji rzadko kiedy programista potrzebuje dostosować działanie silnika wykonawczego platformy .NET do wymagań konstruowanej aplikacji. Powodem tego jest fakt, iż CLR w swojej domyślnej konfiguracji jest zoptymalizowany pod kątem wydajności i bezpieczeństwa właśnie takich aplikacji. Z resztą podstawową konfigurację samego działania CLR taką jak wybór pomiędzy wersją serwerową a workstation czy współbieżność odśmiecacza pamięci (możliwość przeprowadzania oczyszczenia pamięci w wątkach aplikacji lub w wątkach pobocznych) można przeprowadzić wprost z pliku konfiguracyjnego. Istnieją jednak sytuacje, kiedy budowany system ma pewne szczególne wymagania względem silnika wykonawczego, które nie mogą być spełnione przez domyślną konfigurację CLR czy domyślne jego zachowania. Te wymagania mogą dotyczyć takich obszarów jak własny podsystem odpowiedzialny za bezpieczeństwo, ładowanie assemblies ze specyficznych miejsc (np. poprzez sieć) czy własne mechanizmy przydziału pamięci czy tworzenia i szeregowania wątków.

 Aby możliwy był opisany powyżej scenariusz, .NET musi dostarczyć możliwość konfiguracji oraz podmiany działań kluczowych komponentów składających się na silnik wykonawczy platformy. Aby można było dostarczyć własne komponenty CLR’a w celu podmiany domyślnych, należy dostarczyć implementację własnych managerów odpowiedzialnych za funkcjonalność którą chcemy zmienić a która swoim domyślnym zachowaniem nie spełniała wszystkich wymagań aplikacji. Należy wyraźnie zaznaczyć, że decydując się na implementację własnego managera hosta programista musi dokonać pełnej jego implementacji. Nie jest możliwe zaimplementowanie wybranego tylko interfejsu będącego częścią implementowanego managera, i wykorzystanie domyślnych implementacji pozostałych interfejsów, gdyż programista nie posiada dostępu do domyślnych implementacji zawartych w CLR.

Opóźniony start

Mechanizm opóźnionego startu (ang. delayed startup)  nie jest bezpośrednio związany z prezentowaną tematyką, jednak jego znajomość może się przydać w szczególności gdy konstruowany system nie jest implementowany w technologii .NET a napisany jest w klasycznym kodzie niezarządzanym. W takim przypadku często zdarza się, iż CLR nie jest wykorzystywany od razu przez taką aplikację. W szczególności może się zdarzyć, iż aplikacja ani razu nie skorzysta z CLR. Dobrą praktyką jest więc nie inicjowanie w procesie aplikacji silnika wykonawczego wraz z jej uruchomieniem, a tylko dostarczenie własnego mechanizmu uruchamiającego CLR dopiero w momencie, kiedy będzie on rzeczywiście potrzebny. Dzięki temu cały czas programista ma pełną kontrolę nad tym jak Common Language Runtime zostanie załadowany do procesu, jednocześnie nie uruchamiając go od razu oszczędza się w ten sposób zasoby komputera.

Funkcja udostępniająca omawianą funkcjonalność posiada następujący nagłówek.

Listing 1 – wykorzystanie mechanizmu opóźnionego startu

Discovery process

Aby programista mógł wykorzystać możliwość  zmiany zachowania wybranych komponentów CLR, musi dostarczyć implementacje wymaganych interfejsów COM składających się na danego managera hosta. Jednocześnie często trzeba wykorzystać pewne gotowe funkcjonalności oferowane przez silnik wykonawczy takie jak np. zażądanie od garbage collector’a oczyszczenia pamięci. Programista chcący wykorzystać jakiś interfejs managera CLR (np. ICLRGCManager) musi zapytać czy ten interfejs jest przez daną wersję CLR implementowany. Jeżeli tak, można otrzymać do niego wskaźnik. Podobnie musi postąpić CLR w przypadku wszystkich managerów hosta. CLR musi zapytać hosta po kolei, czy dany manager jest przez hosta implementowany. Jeśli tak, host musi zwrócić wskaźnik do głównego interfejsu (ang. primary interface) dzięki któremu CLR będzie mógł wykorzystać dostarczoną funkcjonalność. W obu przedstawionych przypadkach mamy do czynienia z procesem odkrywania (ang. discovery process).

Wśród wszystkich interfejsów składających się na managery hosta i CLR’a, wyróżnić należy dwa, które uczestniczą w procesie odkrywania. Pierwszy z nich, ICLRControl, wykorzystać należy kiedy host chce otrzymać wskaźnik do interfejsu implementowanego przez silnik wykonawczy (ICLR*). Jego definicja przedstawiona została poniżej.

Wskaźnik do tego interfejsu można uzyskać bezpośrednio z uchwytu silnika wykonawczego, interfejsu ICLRRuntimeHost, wykonując na nim metodę GetCLRControl. W jedynym parametrze (wyjściowym) tej funkcji zostanie zwrócony wskaźnik do tego właśnie interfejsu. Bardzo ważne jest, aby tą operację wykonać przed uruchomieniem CLR w procesie (przed wykonaniem metody Start). Inaczej metoda GetCLRControl zwróci błąd.

Powyższy interfejs posiada bardzo ważną metodę – GetCLRManager – która jako pierwszy parametr przyjmuje identyfikator interfejsu, w drugim parametrze zwraca wskaźnik do niego o ile dany interfejs jest implementowany (sama funkcja zwraca wartość S_OK). Jeżeli podany został błędny lub nie obsługiwany identyfikator interfejsu, parametr ppObject przyjmuje wartość NULL, sama funkcja zwróci wartość E_NOINTERFACE. Zwrócony przez powyższą funkcję żądany interfejs można od razu wykorzystać.

Drugim interfejsem, wykorzystywanym przez CLR a implementowanym przez programistę hosta jest interfejs IHostControl. Jego definicja została podana poniżej.

Powyższy interfejs jest jedynym interfejsem, który należy zaimplementować w celu zarejestrowania własnych managerów. Funkcja GetHostManager zostanie automatycznie uruchomiona przez CLR, osobno dla każdego identyfikatora interfejsu hosta który programista może zaimplementować. Dla każdego interfejsu implementowanego należy zwrócić wskaźnik do niego oraz wartość S_OK. Jeżeli danego interfejsu tworzony host nie implementuje, należy w parametrze ppObject zwrócić NULL, sama funkcja musi zwrócić wartość E_NOINTERFACE. W tym miejscu należy wyraźnie zaznaczyć, że funkcja GetHostManager zwraca w parametrze ppObject wskaźnik wyłącznie do głównego interfejsu danego managera (manager jest zbiorem interfejsów COM dostarczających razem pewną określoną funkcjonalność) a nie do pojedynczych interfejsów składających się na danego managera. CLR będzie mieć dostęp do pozostałych interfejsów zaimplementowanego managera poprzez główny interfejs, który na żądanie będzie zwracał CLR’owi pozostałe interfejsy wchodzące w skład danego managera. W tym sensie główny manager pełni rolę fabryki obiektów implementujących interfejsy danego managera.

Managery CLR

W poprzednim punkcie Czytelnik dowiedział się jak uzyskać dostęp do różnych interfejsów implementowanych przez CLR oraz jak uzyskać dostęp do samego interfejsu ICLRControl. Poniżej znajduje się kod programu który zostanie uruchomiony przez prezentowanego w tym podpunkcie hosta. Warto zwrócić uwagę na ostatnią linijkę funkcji Main – w tym miejscu zostanie wypisana liczba przeprowadzonych odmieceń zerowej generacji.

Listing 2 – prosty program w kodzie zarządzanym, uruchamiany przez przykładowego hosta

Poniżej znajduje się program hostujący wykorzystujący omówione do tej pory składniki niezarządzanego API który uruchomi powyższy program. Wykorzystuje on interfejs ICLRGCManager w celu przeprowadzenia odświecania pamięci. Po jej przeprowadzeniu CLR udostępnia statystyki związane z zarządzaną stertą. Aby z nich skorzystać, należy wykonać metodę GetStats która wypełnia danymi strukturę COR_GC_STATS przekazaną jako jedyny parametr tej funkcji (wywołanie funkcji przed przeprowadzeniem odświecania nie zakończy się błędem ale zwrócone zostaną nieprawdziwe informacje). Powyższa struktura posiada jedno ważne pole, Flags, które określa jakimi statystykami host jest zainteresowany. Musi ono zostać ustawione przed wywołaniem funkcji GetStats. Wartości jakie można ustawić to:

·         COR_GC_COUNTS – struktura COR_GC_STATS będzie zawierać wyłącznie informacje o ilości przeprowadzonych odmieceń pamięci

·         COR_GC_MEMORYUSAGE – ustawienie tej flagi spowoduje, iż struktura COR_GC_STATS zawierać będzie informacje o zużyciu pamięci na zarządzanych stertach.

W celu uzyskania pełnej informacji, można wykorzystać alternatywę tych dwóch flag tak jak w przykładzie poniżej. Opis wszystkich pól struktury COR_GC_STATS Czytelnik znajdzie w jej dokumentacji .

Listing 3 – prosty host CLR wykorzystujący managera CLR

Managery hosta

Tworzenie własnych managerów jest często procesem trudnym i skomplikowanym. Odnosi się to w szczególności do managerów hosta odpowiedzialnych za wielowątkowość, synchronizację pomiędzy zadaniami czy zarządzanie pamięcią. W bieżącym przykładzie zostanie przedstawiony prosty host dostarczający własnego managera wielozadaniowości. Jego celem będzie śledzenie zarządzanych wątków oraz wypisanie ich PIDów na końcu jego działania. Można go uruchomić z konsoli podając jako parametr nazwę programu do uruchomienia: DemoHost3.exe mój_prog.exe.

Prezentowany host  składa się z dwóch części – niezarządzanej, która dostarcza implementację własnego managera wielozadaniowości, oraz zarządzanej, która przygotowuje środowisko do uruchomienia właściwego kodu zarządzanego użytkownika (konfiguruje nową AppDomain dla kodu użytkownika). Temat związany z architekturą hosta został omówiony w dalszej części artykułu.

Manager wielozadaniowości (ang. threading manager) posługuje się abstrakcyjnym pojęciem zadania. Jest to najmniejsza jednostka mogąca otrzymać czas procesora. W podstawowej implementacji zadanie jest zaimplementowane w postaci wątku z WIN32 API. W bieżącym przykładzie zadanie również będzie zaimplementowane w oparciu o watki Windows.  Najważniejsze dwa interfejsy wchodzące w skład managera wielozadaniowości to IHostTask – interfejs definiujący podstawowe zachowania zadania, oraz IHostTaskManager – główny interfejs managera wielozadaniowości udostępniający CLR’owi implementację zadania.

IUnknown

Czytelnik z pewnością zwrócił uwagę na interfejs IUnknown z którego dziedziczą wszystkie interfejsy w niezarządzanym API CLR’a. Jest to bazowy interfejs technologii COM który musi być rozszerzony przez każdy inny interfejs który ma być prawidłowym interfejsem COM. Ponieważ całe niezarządzane API oparte jest o tę technologię, wszystkie interfejsy bez wyjątku implementują IUnknown.

Posiada on trzy ważne metody. Dwie z nich, AddRef i Release, implementują zliczanie referencji. Jest to jedno z podejść do zagadnienia automatycznego odświecania pamięci. Za każdym razem kiedy programista chce uzyskać referencję do obiektu, musi zwiększyć licznik referencji metodą AddRef. Kiedy kończy korzystanie z obiektu, zwalnia go zmniejszając liczbę referencji o jeden wywołując metodę Release. Jeżeli licznik referencji spadnie do zera, obiekt jest usuwany z pamięci. Należy pamiętać, aby zwiększanie i zmniejszanie licznika były operacjami atomowymi, inaczej w środowisku wielowątkowym może dojść do wycieku pamięci jeżeli dwa wątki na raz chciałyby zwiększyć lub zmniejszyć licznik. Można w tym celu wykorzystać funkcje InterlockedIncrement oraz InterlockedDecrement. Ostatnia metoda, QueryInterface, służy do zwracania wskaźnika do interfejsu obiektu który dany obiekt może zwrócić. Metoda QueryInterface powinna zawsze zwrócić wskaźnik do własnego obiektu na rzecz którego została wywołana (przez wskaźnik this), jeżeli przekazany jako pierwszy parametr identyfikator interfejsu to IUnknown lub identyfikator interfejsu obiektu na którym wywoływana jest metoda QueryInterface. Metoda ta zawsze powinna wykonać AddRef na interfejsie który jest zwracany (jako drugi parametr).

IHostTask

Implementując ten interfejs programista hosta dostarcza własną wersję zadania. W prezentowanym przykładzie implementacja ta będzie zwykłą realizacją w oparciu o wątki Windows i nie będzie posiadać żadnej specjalnej logiki. Należy jednak pamiętać, iż decydując się na implementację własnego managera należy dostarczyć implementacje wszystkich wymaganych interfejsów.

Z klasą implementującą zadanie związane są dwa obiekty (poprzez kompozycję). Pierwszym obiektem jest uchwyt do wątku który będzie wykonywać dane zadanie. Drugim obiektem jest obiekt implementujący interfejs ICLRTask. Zadanie w CLR jest bowiem reprezentowane przez dwa obiekty które powiązane są ze sobą relacją jeden-do-jeden. Z każdym obiektem IHostTask, Common language Runtime wiąże obiekt ICLRTask od którego można zażądać czynności których IHostTask nie posiada (np. oddać czas procesora innemu zadaniu). CLR sam dokonuje tej asocjacji poprzez wykonanie metody SetCLRTask na interfejsie IHostTask przekazując instancję obiektu ICLRTask jako parametr. Poniżej znajduje się definicja klasy która implementuje zadanie.

Jak widać, sam interfejs IHostTask posiada niewiele metod, ich implementacja sprowadza się do wywoływania odpowiednich funkcji z WIN API. Czytelnik nie powinien mieć problemów z samodzielną ich implementacją.

IHostTaskManager

Jest to główny interfejs managera wielozadaniowości. Dzięki niemu CLR otrzyma dostęp do dostarczonej przez programistę implementacji zadania. Interfejs posiada bardzo dużo metod, jednak aby host nie był przesadnie skomplikowany, ich implementacja została pominięta (host dalej działa poprawnie, takie postępowanie nie jest jednak zalecane). Poniżej znajduje się definicja klasy implementującej ten interfejs (wymienione zostały tylko kluczowe metody).

Z punktu widzenia prezentowanego przykładu najważniejsze dwie metody w interfejsie IHostaTaskManager to CreateTask i GetCurrentTask gdyż w nich zaszyta będzie logika hosta – śledzenie uruchomionych wątków.

Funkcja CreateTask odpowiedzialna jest za stworzenie nowego zadania. Pierwszy parametr określa początkowy rozmiar stosu który ma zostać przydzielony nowo tworzonemu zadaniu. Drugi parametr jest wskaźnikiem do funkcji która zostanie przez zadanie wykonana, trzeci to opcjonalny parametr dla funkcji wykonującej kod użytkownika. W ostatnim parametrze funkcja musi zwrócić wskaźnik do nowo utworzonego zadania. Oczywiście wszystkie parametry poza ostatnim dostarcza CLR gdyż tylko on bezpośrednio wykorzystuje ten interfejs.

Pierwszą czynnością funkcji CreateTask będzie utworzenie nowego wątku w stanie uśpionym (ang. suspended) korzystając z funkcji CreateThread i przekazując jej wyżej wymienione parametry. Kolejną rzeczą jest stworzenie instancji klasy DDHostTask implementującej IHostTask i przekazanie jej uchwytu do utworzonego wątku. Instancję tej klasy należy również zwrócić CLR’owi w ostatnim parametrze. Następnie trzeba zapamiętać parę (ID wątku, zadanie) w strukturze mapy. Informacja ta będzie potrzebna w drugiej funkcji. Ostatnią rzeczą jest wykonanie niezwykle prostej logiki hosta – zapisanie identyfikatora wątku wraz z jego uchwytem w liście. Lista ta pobierana jest z klasy DDContext tworzonej na początku działania hosta. Należy zaznaczyć, iż operacje na wspólnych strukturach danych (w tym przypadku pojemniki lista i mapa) muszą być synchronizowane. Do tego celu można wykorzystać sekcję krytyczną z WIN API która w przykładzie została opakowana w klasie CrstLock. Poniżej znajduje się listing prezentujący omawianą funkcję.

Listing 4 – tworzenie zadania

Ostatnią ważną funkcją jest GetCurrentTask. Funkcja ta powinna zwrócić klasę implementującą zadanie dla wątku z którego nastąpiło jej wywołanie. Ponieważ można bez przeszkód poznać identyfikator wątku z którego nastąpiło wywołanie, poprawną instancję klasy DDHostTask można otrzymać przeszukując mapę wypełnianą w funkcji CreateTask. W funkcji GetCurrentTask znajduje się pewna pułapka. Może bowiem zdarzyć się, iż dany wątek który wywołał metodę GetCurrentTask nie był tworzony przez metodę CreateTask a przez wewnętrzne mechanizmy CLR. W takim przypadku mapa nie będzie zawierać wpisu dla takiego wątku, należy więc utworzyć nową instancję klasy DDHostTask i przypisać jej uchwyt bieżącego wątku. Na końcu należy zaktualizować strukturę mapy i listy. Poniżej znajduje się listing prezentujący omawianą funkcję.

Listing 5 – pobranie klasy zadania dla bieżącego wątku

IHostControl

Po zaimplementowaniu własnego managera ostatnią rzeczą jaką trzeba wykonać jest jego zarejestrowanie w CLR tak aby mógł on być przez niego wykorzystany. Do tego celu służy interfejs IHostControl którego implementację należy dostarczyć. Cała logika rejestrująca znajduje się w funkcji GetHostManager która jest zaimplementowana w klasie DDHostControl (która rozszerza omawiany interfejs). Logika jest niezwykle prosta i sprowadza się do jednej instrukcji warunkowej sprawdzającej czy podany jako pierwszy parametr identyfikator interfejsu jest równy identyfikatorowi głównego interfejsu managera wielowątkowości. Jeżeli tak, zwracany jest do niego wskaźnik poprzez drugi parametr. W każdej innej sytuacji funkcja zwraca E_NOINTERFACE. Poniżej znajduje się kod omawianej funkcji.

Listing 6 – rejestracja managera wielozadaniowości w CLR

Wskaźnik do głównego interfejsu manager wielowątkowości zwracany jest przez funkcję QueryInterface, dzięki temu nie trzeba manualnie inkrementować licznika referencji – odpowiednie wywołanie znajduje się właśnie w QueryInterface.

Mając gotową implementację klasy DDHostControl (implementującej IHostControl), należy przekazać jej instancję CLR’owi. Dokonuje się tego poprzez wywołanie funkcji SetHostControl na uchwycie do silnika wykonawczego (interfejs ICLRRuntimeHost) tak jak pokazano na poniższym listingu.

Listing 7– zarejestrowanie w CLR obiektu DDHostControl

Ważne aby metoda SetHostControl została wykonana przed uruchomieniem CLR’a w procesie. Inaczej jej wywołanie nie przyniesie żadnego efektu.

Architektura

Typowy host CLR jest implementowany w postaci dwóch odrębnych, choć współpracujących modułów. Pierwszy z nich implementowany jest w kodzie niezarządzanym (praktycznie zawsze C++). Jego celem jest wczytanie CLR do procesu, skonfigurowanie i uruchomienie. Moduł ten jest także odpowiedzialny za dostarczenie własnych implementacji managerów hostów. Ta część najczęściej jest zdecydowanie największa i najtrudniejsza w implementacji. Drugi moduł implementowany jest w kodzie zarządzanym jako tzw. Shim i jest odpowiedzialny za przygotowanie środowiska dla zarządzanego kodu użytkownika. Przygotowanie środowiska obejmuje przede wszystkim skonfigurowanie domen aplikacji oraz uruchomienie kodu użytkownika w osobnych wątkach.

Rysunek 1 - typowa architektura hosta CLR

Wykonanie kodu użytkownika w innej niż domyślna domenie aplikacji niesie ze sobą szereg korzyści:

·         Izolacja kodu – kod użytkownika nie będzie wpływał na zarządzaną część hosta. Dodatkowo kod użytkownika może być uruchomiony w wielu różnych domenach aplikacji po to, by newralgiczne jego części były od siebie odseparowane i nie wpływały na siebie.

·         Osobna konfiguracja – każdą AppDomain można oddzielnie skonfigurować przypisując jej wymagane ustawienia w sposób deklaratywny w kodzie. Można także każdej AppDomain osobno przypisać plik xml (App.config) z którego będzie czerpać wszystkie ustawienia.

·         Bezpieczeństwo – dla każdej domeny aplikacji można osobno zdefiniować zasady bezpieczeństwa.

·         Możliwość wyładowania – pojedynczą domenę aplikacji można usunąć z pamięci jeżeli nie jest już dalej potrzebna oddając zasoby systemowi operacyjnemu. Oczywistym jest fakt, że domyślna AppDomain nie może zostać wyładowana bez zamknięcia procesu.

Rozbicie hosta na cześć napisaną w kodzie natywnym i zarządzanym posiada dodatkowo dwie zalety. Po pierwsze zwiększa się nieznacznie wydajność rozwiązania. Ma to związek z tym, iż koszt wywołań pomiędzy kodem zarządzanym i niezarządzanym nie jest zaniedbywalny. Ale jeżeli sterowanie przebiegiem wykonania programu użytkownika przeprowadzane jest przez zarządzaną część hosta, liczba takich wywołań jest zredukowana do niezbędnej komunikacji pomiędzy oboma modułami hosta. Druga zaleta to łatwość implementacji. Jeżeli host musi w jakikolwiek sposób nadzorować wykonywanie kodu użytkownika, taką logikę warto napisać w kodzie zarządzanym gdyż będzie to prostsze zarówno na etapie implementacji, jak i utrzymania. Poniżej znajduje się prosty moduł hosta CLR napisany w kodzie zarządzanym, którego celem jest uruchomienie kodu użytkownika w osobnym wątku i osobnej AppDomain. Host uruchamia swoją zarządzaną część (metoda Start klasy Shim) korzystając z funkcji ExecuteInDefaultAppDomain interfejsu ICLRRuntimeHost.

Podsumowanie

W drugiej części artykułu zostały poruszone bardziej zaawansowane tematy związane z tworzeniem własnej warstwy hostującej silnik wykonawczy platformy Microsoft .NET. Przedstawiony został zarówno mechanizm wykorzystania managerów CLR jak i sposób dostarczenia własnych implementacji managerów CLR. Na koniec została przedstawiona architektura poprawnie zaprojektowanego hosta. Artykuł omawia zaledwie niezbędne podstawy które umożliwią Czytelnikowi dalsze eksperymenty z niezarządzanym API jakie dostarcza firma Microsoft wraz ze swoją nowoczesną platformą programistyczną. To właśnie dzięki możliwości tworzenia własnych hostów .NET Framework jest tak konfigurowalny i rozszerzalny. Dzięki temu, dla platformy Microsoft .NET mogą powstawać najbardziej skomplikowane systemy komputerowe mogące sprostać dzisiejszym wymaganiom.

Referencje

[1] CLR Inside Out: CLR hosting APIs, Alessandro Catorcini and Piotr Puszkiewicz

http://msdn.microsoft.com/msdnmag/issues/06/08/CLRInsideOut/default.aspx

[2] Bart De Smet's on-line blog

http://community.bartdesmet.net/blogs/bart/default.aspx

[3] Implement a Custom Common Language Runtime Host for Your Managed App, Steven Pratschner

http://msdn.microsoft.com/msdnmag/issues/01/03/clr/

[4] A Tour of the CLR Hosting API

http://www.programmingtutorialz.com/articles/59/1/A-Tour-of-the-CLR-Hosting-API

[5] Unmanaged API Reference

http://msdn2.microsoft.com/en-us/library/ms404385.aspx