Gibt es einen starken Grund, warum Microsoft AppDomains in .NET Core nicht unterstützt?

AppDomains sind besonders nützlich, wenn Sie Server-Apps mit langer Laufzeit erstellen, bei denen wir die vom Server geladenen Assemblys auf anmutige Weise aktualisieren möchten, ohne den Server herunterzufahren.

Wie können wir ohne AppDomains unsere Assemblys in einem lang laufenden Serverprozess ersetzen?

AppDomains bieten uns auch die Möglichkeit, verschiedene Teile des Servercodes zu isolieren. Ein benutzerdefinierter Websocket-Server kann Socket-Code in der primären App-Domäne haben, während unsere Dienste in der sekundären App-Domäne ausgeführt werden.

Ohne AppDomains ist das obige Szenario nicht möglich.

Ich sehe ein Argument, das möglicherweise über die Verwendung des Cloud-Konzepts von VMs zur Behandlung von Baugruppenänderungen spricht und nicht den Aufwand für AppDomains verursachen muss. Aber denkt oder sagt Microsoft das? oder haben sie einen bestimmten Grund und Alternativen für die oben genannten Szenarien?

Der Zweck der .NETCore-Teilmenge bestand darin, eine .NET-Installation klein zu halten . Und einfach zu portieren. Aus diesem Grund können Sie beispielsweise eine Silverlight-App unter Windows und OSX ausführen und nicht lange warten, wenn Sie die Webseite besuchen. Das Herunterladen und Installieren der gesamten Laufzeit und des Frameworks dauert einige Sekunden.

Um es klein zu halten, müssen zwangsläufig Merkmale geschnitten werden. Remoting stand ganz oben auf dieser Liste, es ist ziemlich teuer. Ansonsten gut versteckt, aber Sie können zum Beispiel sehen, dass Delegaten keine funktionierende BeginInvoke () -Methode mehr haben. Damit AppDomain ebenfalls auf die Schnittliste gesetzt wird, können Sie keinen Code in einer App-Domäne ausführen, ohne Unterstützung für Remoting zu erhalten. Das ist also völlig beabsichtigt.

Update für .NET Standard 2 und .NET Core 2

In .NET Standard 2 die AppDomainKlasse ist da drin. Viele Teile dieser API werfen jedoch einen PlatformNotSupportedExceptionfür .NET Core.

Der Hauptgrund , es ist immer noch da drin ist für grundlegenden Dinge wie ein nicht behandelte Exception - Handler registrieren , die wird funktionieren.

Die .NET Standard-FAQ enthält folgende Erklärung :

Ist AppDomain Teil von .NET Standard?

Der AppDomain-Typ ist Teil von .NET Standard. Nicht alle Plattformen unterstützen die Erstellung neuer App-Domänen, z. B. .NET Core nicht. Daher kann die in .NET Standard verfügbare Methode AppDomain.CreateDomain PlatformNotSupportedException auslösen.

Der Hauptgrund, warum wir diesen Typ in .NET Standard verfügbar machen, ist, dass die Nutzung ziemlich hoch ist und normalerweise nicht mit dem Erstellen neuer App-Domänen verbunden ist, sondern mit der Interaktion mit der aktuellen App-Domäne, z. B. dem Registrieren eines nicht behandelten Ausnahmebehandlers oder dem Abfragen des Basisverzeichnisses der Anwendung .

Abgesehen davon erklären die Top-Antwort und andere Antworten auch gut, warum der Großteil von AppDomain immer noch gekürzt wurde (z. B. löst eine nicht unterstützte Ausnahme aus).

App Domains

Warum wurde es eingestellt? AppDomains benötigen Laufzeitunterstützung und sind im Allgemeinen recht teuer. Obwohl es noch von CoreCLR implementiert ist, ist es in .NET Native nicht verfügbar, und wir planen nicht, diese Funktion dort hinzuzufügen.

Was soll ich stattdessen verwenden? AppDomains wurden für verschiedene Zwecke verwendet. Zur Code-Isolierung empfehlen wir Prozesse und / oder Container. Zum dynamischen Laden von Assemblys empfehlen wir die neue AssemblyLoadContext-Klasse.

Quelle aus dem MSDN-Blog

Irgendwann hörte ich, dass das Entladen von Assemblys ohne Verwendung von Domänen aktiviert werden würde. Ich denke, dass der System.Runtime.Loader.AssemblyLoadContextTyp in System.Runtime.Loader.dll mit dieser Arbeit zusammenhängt, aber ich sehe dort noch nichts, was das Entladen ermöglicht.

Ich habe in einem Community-Standup oder in einem Vortrag von Microsoft gehört, dass die Isolationsfunktion von AppDomains besser von Prozessen (und tatsächlich das übliche Muster auf anderen Plattformen) gehandhabt wird und das Entladen tatsächlich als normale Funktion geplant ist, die nichts mit AppDomains zu tun hat.

Sie brauchen keine AppDomains mehr, Sie haben jetzt LoadContexts:

public class CollectibleAssemblyLoadContext 
    : AssemblyLoadContext
{
    public CollectibleAssemblyLoadContext() : base(isCollectible: true)
    { }
 
    protected override Assembly Load(AssemblyName assemblyName)
    {
        return null;
    }
}

byte[] result = null; // Assembly Emit-result from roslyn
System.Runtime.Loader.AssemblyLoadContext context = new CollectibleAssemblyLoadContext();
System.IO.Stream ms = new System.IO.MemoryStream(result);
System.Reflection.Assembly assembly = context.LoadFromStream(ms);


System.Type programType = assembly.GetType("RsEval");
MyAbstractClass eval = (MyAbstractClass )System.Activator.CreateInstance(programType);
eval.LoadContext = context;
eval.Stream = ms;
// do something here with the dynamically created class "eval"

und dann kann man sagen

eval.LoadContext.Unload();
eval.Stream.Dispose();

Bonus, wenn Sie das in die IDisposable-Oberfläche der abstrakten Klasse einfügen, können Sie es einfach verwenden, wenn Sie möchten.