Non capisco Domini applicazione

Question

.NET ha questo concetto di domini dell'applicazione che, da quello che ho capito, può essere utilizzato per caricare un assembly in memoria. Ho fatto qualche ricerca su Application Domains e sono andato nel mio negozio di libri locale per avere ulteriori informazioni su questo argomento, ma sembra molto scarso.

Tutto quello che so che posso fare con Application Domains è caricare gli assembly in memoria e posso scaricarli quando voglio.

Quali sono le altre funzionalità che ho menzionato su Application Domains? I thread rispettano i confini dei domini dell'applicazione? Ci sono degli svantaggi dal caricamento di Assemblies in diversi domini applicativi diversi dai Domain Application principali oltre le prestazioni di comunicazione?

Anche i collegamenti alle risorse che trattano dei domini dell'applicazione sono utili. Ho già controllato MSDN che non ha molte informazioni su di loro.

Answer 1

AppDomains meglio visualizzato come un processo molto leggero.

Possono esserci N AppDomains per .Net Process ma in generale c'è solo uno. Il vero vantaggio di AppDomains è che forniscono un limite di isolamento all'interno del processo. Gli oggetti possono comunicare tra loro solo attraverso un limite di AppDomain tramite remoting o serializzazione.

È anche possibile eseguire 2 AppDomain a livelli di sicurezza completamente diversi all'interno di un processo. Questo può consentire di eseguire l'applicazione principale su Full Trust durante l'esecuzione di Plug-in non attendibili a un livello di fiducia molto più basso.

È difficile dire "sì" o "no" se un thread rispetta o meno un AppDomain. È possibile che un singolo thread si trovi in ​​N diversi AppDomain. Tale situazione è possibile se un oggetto in un AppDomain effettua una chiamata remota a un oggetto in un altro AppDomain. Il thread dovrà passare tra gli AppDomain per completare.

Lo svantaggio di AppDomains è principalmente la complessità. I servizi remoti possono richiedere un po 'di tempo per capirlo e impostare correttamente un AppDomain può essere un processo non banale.

Si consiglia di dare un'occhiata alla documentazione MSDN su AppDomains. È difficile trovare un tutorial di successo che li descriva perché hanno una varietà di funzioni complesse. Ciò fornisce una buona panoramica che, se non risponde direttamente alla tua domanda, ti indirizzerà almeno nel posto giusto.

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

Questo documento non è più mantenuto prega di fare riferimento a questo per la versione aggiornata: https://msdn.microsoft.com/en-us/library/2bh4z9hs(v=vs.110).aspx

Answer 2

Alcune cose si possono fare con AppDomain:

• si può spegnerlo senza mettendo in pericolo la stabilità del tuo programma.
• È possibile caricare il codice e assegnare questo privilegio al proprio processo (ad esempio, il processo viene eseguito completamente affidabile ma si carica il codice in un AppDomain separato che non può nemmeno creare un file sul disco.)
• È possibile gestire eccezioni non gestite di un AppDomain senza dover arrestare il processo.
• Ecc.

In poche parole, è un limite di sicurezza e un limite del processo. Per quanto riguarda le prestazioni, più AppDomain all'interno di un processo non rappresentano un sovraccarico significativo. Avviare un processo separato invece di un AppDomain è molto più costoso.

Answer 3

La risposta di JaredPar è buona, ad eccezione del fatto che non nota lo raison d'etre per AppDomains, ovvero che è possibile SCARICARE un assembly scaricando il relativo AppDomain. Se si utilizza un processo operativo a esecuzione prolungata e si prevede di caricare e successivamente scaricare gli assembly per qualsiasi motivo, è necessario un AppDomain. L'esempio prototipo qui è ASP.NET, che carica gli assembly del codice app su richiesta e quindi può scaricarli in un secondo momento, quando le app non vengono più utilizzate attivamente.

Il costo che si paga per la capacità di scaricare è tale indipendenza: è necessario comunicare attraverso il confine AppDomain, Impossibile effettuare una chiamata al metodo semplice. È necessario gestire il ciclo di vita di AppDomain. Ecc

Se avete solo bisogno di caricare dinamicamente Assemblee e non pensate è necessario scaricarli durante la vita di un singolo processo allora probabilmente non è necessario eseguire più AppDomain. Un buon esempio potrebbe essere un'app ricca che supporta un modello plug-in, in cui annusa gli assembly plug-in in una directory "etc" e li carica tutti. Tuttavia, se il modello plug-in richiede lo scarico dei plug-in ... beh.

Esistono scenari esterni. Ad esempio, supponiamo di voler caricare 2 versioni differenti di un assieme nello stesso momento. È possibile incorrere in insidie ​​se non si segrega con AppDomains. Ma sarà abbastanza raro.

Lo scenario principale che giustifica l'esistenza di AppDomains è il processo a esecuzione prolungata che deve essere in grado di scaricare gli assembly.

Naturalmente, le applicazioni possono fare affidamento sul processo del sistema operativo quando si desidera scaricare un assieme. In altre parole, è possibile che siano in esecuzione 3 o 4 processi cooperanti, ognuno con il proprio set di assiemi, e quando si desidera scaricare un assembly, è sufficiente arrestare il processo che ospita quell'assembly. Ma l'AppDomain offre un meccanismo più perfetto per farlo, senza richiedere processi stop/start o cross-process, che è ancora più pesante delle comunicazioni cross-AppDomain descritte in precedenza. Voglio dire che è ancora in servizio remoto, ma è più lento e più commutazione di contesto.