C'è un motivo valido per cui Microsoft ha scelto di non supportare AppDomain in .NET Core?

Gli AppDomain sono particolarmente utili quando si creano app server a esecuzione prolungata, in cui è possibile che si desideri aggiornare gli assembly caricati dal server in modo aggraziato, senza arrestare il server.

Senza AppDomains, come sostituiremo i nostri assembly in un processo server di lunga durata?

AppDomain ci fornisce anche un modo per isolare diverse parti del codice del server. Ad esempio, un server websocket personalizzato può avere codice socket nel dominio app principale, mentre i nostri servizi vengono eseguiti nel dominio app secondario.

Senza AppDomains, lo scenario precedente non è possibile.

Posso vedere un argomento che potrebbe parlare dell'utilizzo del concetto di cloud delle VM per la gestione delle modifiche agli assembly e per non dover sostenere l'overhead di AppDomain. Ma è questo ciò che Microsoft pensa o dice? o hanno una ragione specifica e alternative per gli scenari di cui sopra?

Lo scopo del sottoinsieme .NETCore era mantenere un'installazione .NET ridotta . E facile da portare. Ecco perché puoi, ad esempio, eseguire un'app Silverlight sia su Windows che su OSX e non aspettare molto a lungo quando visiti la pagina web. Il download e l'installazione dell'intero runtime e del framework richiede una manciata di secondi, più o meno.

Mantenerlo piccolo richiede inevitabilmente che le caratteristiche vengano tagliate. Il remoting era molto in cima a quella lista, è piuttosto costoso. Altrimenti ben nascosto, ma puoi ad esempio vedere che i delegati non hanno più un metodo BeginInvoke () funzionale. Il che mette anche AppDomain nell'elenco di taglio, non è possibile eseguire codice in un dominio dell'app senza il supporto remoto. Quindi questo è interamente in base alla progettazione.

Aggiornamento per .NET Standard 2 e .NET Core 2

In .NET Standard 2 la AppDomainclasse è lì. Tuttavia, molte parti di tale API genereranno un PlatformNotSupportedExceptionper .NET Core.

Il motivo principale è ancora in là è per cose di base come la registrazione di un gestore di eccezione non gestita, che si funzionerà.

Le domande frequenti su .NET Standard hanno questa spiegazione :

AppDomain fa parte di .NET Standard?

Il tipo AppDomain fa parte di .NET Standard. Non tutte le piattaforme supporteranno la creazione di nuovi domini di app, ad esempio .NET Core no, quindi il metodo AppDomain.CreateDomain, pur essendo disponibile in .NET Standard, potrebbe generare PlatformNotSupportedException.

Il motivo principale per cui esponiamo questo tipo in .NET Standard è perché l'utilizzo è piuttosto elevato e in genere non è associato alla creazione di nuovi domini dell'app, ma all'interazione con il dominio dell'app corrente, come la registrazione di un gestore di eccezioni non gestito o la richiesta della directory di base dell'applicazione .

A parte questo, la risposta principale e altre risposte spiegano anche bene perché la maggior parte di AppDomain è stata ancora tagliata (ad esempio, genera un'eccezione non supportata).

Domini delle app

Perché è stato interrotto? Gli AppDomain richiedono il supporto del runtime e sono generalmente piuttosto costosi. Sebbene sia ancora implementato da CoreCLR, non è disponibile in .NET Native e non abbiamo intenzione di aggiungere questa funzionalità lì.

Cosa dovrei usare invece? Gli AppDomain sono stati utilizzati per scopi diversi. Per l'isolamento del codice, consigliamo processi e / o contenitori. Per il caricamento dinamico degli assembly, si consiglia la nuova classe AssemblyLoadContext.

Fonte dal blog MSDN

A un certo punto, ho sentito che lo scaricamento degli assembly sarebbe stato abilitato senza utilizzare i domini. Penso che il System.Runtime.Loader.AssemblyLoadContexttipo in System.Runtime.Loader.dll sia correlato a questo lavoro, ma non vedo ancora nulla che consenta lo scaricamento.

Non hai più bisogno di AppDomain, ora hai 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"

e poi puoi dire

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

Bonus se lo metti nell'interfaccia IDisposable della classe astratta, puoi semplicemente usare using, se lo desideri.

Nota:
questo presuppone una classe astratta fissa in un assembly comune

public abstract class MyAbstractClass 
{

     public virtual void foo()
     {}
}

e una classe generata dinamicamente dal runtime (utilizzando Roslyn), che fa riferimento alla classe astratta nell'assembly comune, che implementa ad esempio:

public class RsEval: MyAbstractClass 
{

     public override void foo()
     {}
}

Ho sentito in uno stand-up della comunità o in alcuni discorsi di Microsoft che la funzionalità di isolamento di AppDomain è gestita meglio dai processi (e in realtà lo schema comune in altre piattaforme) e lo scarico è effettivamente pianificato come una normale funzionalità non correlata ad AppDomain.