Ich verstehe Anwendungsdomänen nicht

.NET hat dieses Konzept von Anwendungsdomänen, mit denen meines Wissens eine Assembly in den Speicher geladen werden kann. Ich habe einige Nachforschungen über Anwendungsdomänen angestellt und bin zu meinem örtlichen Buchladen gegangen, um zusätzliches Wissen zu diesem Thema zu erhalten, aber es scheint sehr selten zu sein.

Ich weiß nur, dass ich mit Anwendungsdomänen Assemblys in den Speicher laden und sie entladen kann, wenn ich möchte.

Welche anderen Funktionen habe ich für Anwendungsdomänen erwähnt? Respektieren Threads die Grenzen von Anwendungsdomänen? Gibt es Nachteile beim Laden von Baugruppen in andere Anwendungsdomänen als die Hauptanwendungsdomänen, die über die Kommunikationsleistung hinausgehen?

Links zu Ressourcen, die sich mit Anwendungsdomänen befassen, wären ebenfalls hilfreich. Ich habe bereits MSDN ausgecheckt, das nicht so viele Informationen über sie enthält.

AppDomains lassen sich am besten als sehr leichter Prozess visualisieren.

Es können N AppDomains pro .Net-Prozess vorhanden sein, aber im Allgemeinen gibt es nur eine. Der eigentliche Vorteil von AppDomains besteht darin, dass sie eine Isolationsgrenze innerhalb Ihres Prozesses darstellen. Objekte können nur über Remoting oder Serialisierung über eine AppDomain-Grenze hinweg miteinander kommunizieren.

Es ist auch möglich, 2 AppDomains mit völlig unterschiedlichen Sicherheitsstufen innerhalb eines Prozesses auszuführen. Auf diese Weise können Sie Ihre Hauptanwendung mit voller Vertrauenswürdigkeit ausführen, während Sie nicht vertrauenswürdige Plugins mit einer viel niedrigeren Vertrauensstufe ausführen.

Es ist schwer zu sagen, ob ein Thread eine AppDomain respektiert oder nicht. Es ist möglich, dass sich ein einzelner Thread in N verschiedenen AppDomains befindet. Eine solche Situation ist möglich, wenn ein Objekt in einer AppDomain einen Fernaufruf an ein Objekt in einer anderen AppDomain ausführt. Der Thread muss zwischen den AppDomains wechseln, um abgeschlossen zu werden.

Der Nachteil von AppDomains ist hauptsächlich die Komplexität. Das Remoting kann einige Zeit in Anspruch nehmen, um sich zurechtzufinden, und das ordnungsgemäße Einrichten einer AppDomain kann ein nicht trivialer Prozess sein.

Vielleicht möchten Sie einen Blick in die MSDN-Dokumentation zu AppDomains werfen. Es ist schwierig, ein kurzes Tutorial zu finden, das sie beschreibt, da sie eine Vielzahl komplexer Funktionen aufweisen. Dies bietet einen schönen Überblick, der Sie zumindest an die richtige Stelle bringt, wenn Ihre Frage nicht direkt beantwortet wird.

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

Dieses Dokument wird nicht mehr gepflegt. Die aktualisierte Version finden Sie hier: https://msdn.microsoft.com/en-us/library/2bh4z9hs(v=vs.110).aspx

JaredPar Antwort ist gut, außer er nicht die nicht beachten raison d'etre für AppDomains - das ist , dass Sie nur eine Versammlung UNLOAD kann durch seine AppDomain entladen. Wenn Sie ein Betriebssystem mit langer Laufzeit sind und erwarten, dass Sie Assemblys aus irgendeinem Grund laden und später entladen müssen, benötigen Sie eine AppDomain. Das prototypische Beispiel hierfür ist ASP.NET, das App-Code-Assemblys bei Bedarf lädt und sie später entladen kann, wenn die Apps nicht mehr aktiv verwendet werden.

Die Kosten, die Sie für das Entladen bezahlen, sind die Unabhängigkeit - Sie müssen über die AppDomain-Grenze kommunizieren. Es kann kein einfacher Methodenaufruf durchgeführt werden. Sie müssen den AppDomain-Lebenszyklus verwalten. Etc.

Wenn Sie Assemblies nur dynamisch laden müssen und nicht glauben, dass Sie sie während der Lebensdauer eines einzelnen Prozesses entladen müssen, müssen Sie wahrscheinlich nicht mehrere AppDomains ausführen. Ein gutes Beispiel hierfür könnte eine umfangreiche App sein, die ein Plug-In-Modell unterstützt, bei dem Plug-In-Assemblys in einem "etc" -Verzeichnis aufgespürt und alle geladen werden. Wenn das Plug-In-Modell jedoch das Entladen der Plug-Ins erfordert ... na ja.

Es gibt äußere Szenarien. Angenommen, Sie möchten zwei verschiedene Versionen einer Baugruppe gleichzeitig laden. Sie können auf Fallstricke stoßen, wenn Sie sie nicht mit AppDomains trennen. Aber das wird ziemlich selten sein.

Das Kernszenario, das die Existenz von AppDomains rechtfertigt, ist der lang laufende Prozess, der Assemblys entladen kann.

Natürlich können sich Anwendungen auf den Betriebssystemprozess verlassen, wenn Sie eine Assembly entladen möchten. Mit anderen Worten, es können 3 oder 4 kooperierende Prozesse mit jeweils eigenen Assemblys ausgeführt werden. Wenn Sie eine Assembly entladen möchten, fahren Sie einfach den Prozess herunter, der diese Assembly hostet. Die AppDomain bietet jedoch einen leistungsstärkeren Mechanismus, ohne dass Prozessstopp / -start oder prozessübergreifende Kommunikation erforderlich sind, der noch schwerer ist als die zuvor beschriebenen appDomainübergreifenden Kommunikation. Ich meine, es ist immer noch Remoting, aber es ist langsamer und mehr Kontextwechsel.

Einige Dinge, die Sie mit AppDomains tun können:

• Sie können es herunterfahren, ohne die Stabilität Ihres Programms zu gefährden.
• Sie können Code laden und diesem weniger Berechtigungen als Ihrem eigenen Prozess erteilen (z. B. wird Ihr Prozess vollständig vertrauenswürdig ausgeführt, aber Sie laden Code in eine separate AppDomain, die nicht einmal eine Datei auf der Festplatte erstellen kann.)
• Sie können nicht behandelte Ausnahmen einer AppDomain verarbeiten, ohne Ihren Prozess zum Absturz bringen zu müssen.
• Etc.

Einfach ausgedrückt ist es eine Sicherheitsgrenze und fast eine Prozessgrenze. In Bezug auf die Leistung bedeuten mehrere AppDomains innerhalb eines Prozesses keinen signifikanten Overhead. Das Starten eines separaten Prozesses anstelle einer AppDomain ist weitaus kostspieliger.