Nie rozumiem domen aplikacji

NET ma taką koncepcję domen aplikacji, które z tego, co rozumiem, mogą być używane do ładowania zestawu do pamięci. Zrobiłem kilka badań na temat domen aplikacji, a także poszedłem do mojej lokalnej księgarni, aby uzyskać dodatkową wiedzę na ten temat, ale wydaje się ona bardzo ograniczona.

Wszystko, co wiem, że mogę zrobić z domenami aplikacji, to ładować zestawy do pamięci i mogę je zwolnić, kiedy chcę.

Jakie są inne możliwości domen aplikacji, o których wspomniałem? Czy wątki respektują granice domen aplikacji? Czy są jakieś wady ładowania zestawów w różnych domenach aplikacji innych niż główne domeny aplikacji poza wydajnością komunikacji?

Przydałyby się również linki do zasobów omawiających domeny aplikacji. Sprawdziłem już MSDN, które nie zawiera zbyt wielu informacji na ich temat.

AppDomains najlepiej wizualizować jako bardzo lekki proces.

Na proces .Net może przypadać N domen aplikacji, ale ogólnie jest tylko jedna. Prawdziwą zaletą AppDomains jest to, że zapewniają granicę izolacji w ramach Twojego procesu. Obiekty mogą rozmawiać ze sobą tylko przez granicę AppDomain za pośrednictwem komunikacji zdalnej lub serializacji.

Możliwe jest również uruchomienie 2 AppDomains na zupełnie różnych poziomach bezpieczeństwa w ramach procesu. Może to pozwolić na uruchomienie głównej aplikacji z pełnym zaufaniem podczas uruchamiania niezaufanych wtyczek na znacznie niższym poziomie zaufania.

Trudno jest ogólnie powiedzieć tak lub nie, czy wątek respektuje AppDomain. Pojedynczy wątek może znajdować się w N różnych domenach aplikacji. Taka sytuacja jest możliwa, jeśli obiekt w jednej AppDomain wykonuje zdalne wywołanie obiektu w innej AppDomain. Wątek będzie musiał przejść między domenami aplikacji, aby zakończyć.

Wadą AppDomains jest głównie złożoność. Praca zdalna może zająć trochę czasu, a prawidłowe skonfigurowanie domeny AppDomain może być nietrywialnym procesem.

Możesz zajrzeć do dokumentacji MSDN w AppDomains. Trudno znaleźć zwięzły samouczek, który je opisuje, ponieważ mają one wiele złożonych funkcji. Zapewnia to ładny przegląd, który jeśli nie odpowiada bezpośrednio na twoje pytanie, przynajmniej wskaże ci właściwe miejsce.

http://msdn.microsoft.com/en-us/library/cxk374d9.aspx

Ten dokument nie jest już aktualizowany. W celu uzyskania zaktualizowanej wersji zapoznaj się z nim: https://msdn.microsoft.com/en-us/library/2bh4z9hs(v=vs.110).aspx

Odpowiedź JaredPara jest dobra, z wyjątkiem tego, że nie zauważa racji bytu dla AppDomains - czyli tego, że można WYŁADOWAĆ zestaw tylko poprzez wyładowanie jego AppDomain. Jeśli jesteś długotrwałym procesem systemu operacyjnego i spodziewasz się, że będziesz musiał załadować, a następnie zwolnić zestawy z dowolnego powodu, potrzebujesz AppDomain. Prototypowym przykładem jest tutaj ASP.NET, który ładuje zestawy kodu aplikacji na żądanie, a następnie może je zwolnić później, gdy aplikacje nie są już aktywnie używane.

Koszt, który płacisz za możliwość wyładowania, to niezależność - musisz komunikować się przez granicę AppDomain, nie można wykonać prostego wywołania metody. Musisz zarządzać cyklem życia AppDomain. Itp.

Jeśli potrzebujesz tylko dynamicznie ładować zestawy i nie sądzisz, że będziesz musiał je wyładowywać w trakcie trwania pojedynczego procesu , prawdopodobnie nie musisz uruchamiać wielu AppDomains. Dobrym przykładem może być tutaj rozbudowana aplikacja, która obsługuje model wtyczek, w której wyszukuje zestawy wtyczek w katalogu „etc” i ładuje je wszystkie. Jeśli jednak model wtyczki wymaga wyładowania wtyczek ... cóż.

Istnieją scenariusze zewnętrzne. Przypuśćmy, że chcesz załadować 2 różne wersje zestawu w tym samym czasie. Możesz napotkać pułapki, jeśli nie oddzielisz ich za pomocą AppDomains. Ale to będzie dość rzadkie.

Podstawowy scenariusz, który uzasadnia istnienie AppDomains, to długotrwały proces, który musi mieć możliwość zwalniania zestawów.

Oczywiście aplikacje mogą polegać na procesie systemu operacyjnego, gdy chcesz zwolnić zestaw. Innymi słowy, możesz mieć uruchomione 3 lub 4 współpracujące procesy, każdy z własnym zestawem zestawów, a gdy chcesz zwolnić zestaw, po prostu zamknij proces, który obsługuje ten zestaw. Ale AppDomain oferuje mechanizm o wyższej wydajności, który to robi, bez konieczności zatrzymywania / uruchamiania procesu lub komunikacji między procesami, co jest jeszcze cięższe niż opisane wcześniej komunikaty cross-AppDomain. Chodzi mi o to, że nadal jest zdalny, ale jest wolniejszy i bardziej przełącza kontekst.

Niektóre rzeczy, które możesz zrobić z AppDomains:

• możesz go zamknąć bez narażania stabilności programu.
• Możesz załadować kod i nadać mu mniej uprawnień niż własny proces (np. Twój proces działa w pełni zaufany, ale ładujesz kod w oddzielnej domenie aplikacji, która nie może nawet utworzyć pliku na dysku).
• Możesz obsłużyć nieobsłużone wyjątki AppDomain bez konieczności zawieszania procesu.
• Itp.

Mówiąc najprościej, jest to granica bezpieczeństwa i prawie granica procesu. Jeśli chodzi o wydajność, wiele domen AppDomains w ramach procesu nie stanowi znaczącego obciążenia. Uruchomienie oddzielnego procesu zamiast domeny AppDomain jest znacznie bardziej kosztowne.