MEF non supporta isolamento AppDomain, quindi purtroppo, anche durante ricomposizione, quei gruppi che erano stati precedentemente caricati sono ancora caricati nella principale AppDomain applicazione web. Ci sono due cose che avresti bisogno di combattere in ASP.NET:
Eventuali modifiche apportate ai file fisici (ad esempio aspx, .cshtml, ecc), o eventuali modifiche ai file di configurazione (config), o eventuali modifiche alla directory \ bin causeranno il riciclo dell'applicazione. Ciò è dovuto a due cose: il monitoraggio dei file delle pagine/config e il monitoraggio dei file della directory \ bin (che è perché, per impostazione predefinita, ASP.NET utilizza la copia shadow dei file - questo è raccomandato).
Per utilizzare MEF in un altro AppDomain sarebbe necessaria una quantità orribile di comunicazioni tra domini, tramite la serializzazione o MarshalByRef, che non penso sarebbe mai stata un'implementazione pulita. Non sai come attivare le istanze di BuildProvider utilizzate per compilare in modo dinamico le tue pagine in un altro AppDomain.
Mi chiedo se stai pensando troppo a questo. Da IIS6, HTTP.SYS ha gestito il routing delle richieste in arrivo sul sito Web appropriato, gestito a livello di kernel. Anche se l'applicazione principale si è riavviata (e ci sono una serie di motivi per cui potrebbe essere), nessuna richiesta verrà eliminata, si accoderebbe semplicemente in attesa di un nuovo processo di lavoro prima di inoltrare la richiesta. Certo, dal punto di vista dell'utente, potrebbero notare un po 'di tempo in attesa che la nuova applicazione si riavvii, ma realisticamente, con quale frequenza farai queste modifiche?
Un sacco di progettazione delle applicazioni soffre di sovradimensionamento. Si consiglia di progettare per ogni scenario, ma realisticamente è più semplice mantenere un sistema semplice ma estensibile. Secondo me, voler fare ciò che hai specificato sarebbe classificato come over-engineering. Mantienilo semplice.
fonte
2011-09-29 07:31:54
Quindi la tua raccomandazione in breve è quindi di riciclare il pool e poi ricaricherà i nuovi assembly? Ti sto capendo correttamente? – Mark
In una parola, sì. Potrebbe sembrare una risposta deludente per te, ma le applicazioni ASP.NET sono progettate per funzionare in questo modo. Quando stai pianificando il set di funzionalità per la tua applicazione, vale la pena considerare se la funzione che stai progettando è per i casi d'uso più comuni o meno. Ha senso? –
Mi è venuta l'idea di creare un'applicazione di sottorete (applicazioni Web nidificate) in modo da poter riciclare l'applicazione figlio e non il genitore. Cosa ne pensi di questo? Potrebbe essere un po 'più di lavoro, ma mi dà più flessibilità, no? – Mark