Cosa succede quando carico un assieme?

Question

Nella mia applicazione ASP.NET MVC, Ho la seguente configurazione:

<runtime> 
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
     <probing privatePath="bin;extras"/> 

ho fatto riferimento assemblee si trovano nella cartella extras nelle viste e hanno funzionato perfettamente (usando <%@ Import Namespace="myNameSpace" %>).

Le mie domande

1. che cosa accade quando quella linea si chiama?
2. Dove viene caricato l'assieme?
3. Perché non riesco a sovrascrivere l'assembly situato nella cartella extras che contiene myNameSpace con una versione più recente? (Ricevo un errore che dice che l'assembly è "aperto" in un altro programma)
4. C'è un modo per sovrascrivere l'assembly con una versione più recente senza dover riavviare l'applicazione?

Answer 1

1) L'importazione non esegue effettivamente nulla in fase di esecuzione. È una comodità in fase di compilazione che consente di fare riferimento ai tipi utilizzando i loro nomi non qualificati come Ambiente invece di System.Environment.

2) Il gruppo viene caricato utilizzando le normali regole di verifica dell'assemblaggio. Il CLR controlla varie posizioni prima di questi percorsi di esplorazione privati, quindi è importante tenerlo a mente. Se si fa riferimento a un assembly con nome sicuro e si prevede di trovare tale assembly in un percorso di rilevamento privato, si preferirebbe un assembly con lo stesso nome sicuro (nome, versione, chiave pubblica, ecc.) Nella GAC. Questo a volte può portare a comportamenti imprevisti e di solito è causato dalla codifica hard di una versione di assembly in AssemblyInfo.cs e dalla dimenticanza di aggiornarlo.

3) Una volta caricato, non è possibile scaricare un assieme senza scaricare AppDomain. Ma ASP.NET usa "shadow copying" che significa che gli assembly vengono copiati su un percorso temporaneo prima di essere caricati. Questo dovrebbe lasciare l'assembly originale sbloccato e in grado di essere sovrascritto. In cima alla mia testa, non sono sicuro del motivo per cui avresti ricevuto l'errore sugli assembly bloccati. In una normale applicazione Windows, questo sarebbe del tutto normale e previsto. Ma ASP.NET è progettato in modo da poter sovrascrivere contenuto, codice, assiemi, ecc. Mentre l'applicazione è in esecuzione, il che porta al n.

4) In pratica, n. Poiché non è possibile scaricare un assieme, non è possibile aggiornare un assieme senza riavviare l'applicazione Web. Tecnicamente parlando, puoi caricare più versioni di un assembly ma questo non ti darebbe i risultati desiderati. Qualsiasi riferimento in fase di compilazione farebbe comunque riferimento al vecchio assembly e si otterrebbero tutti i tipi di eccezioni di cast non valide se si tentasse di utilizzare il nuovo assembly. Ma come ho detto in # 3, con ASP.Gli assembly di aggiornamento NET dovrebbero essere semplici come la sostituzione dei file e dovrebbero avvenire automaticamente. Non è necessario riavviare IIS o i processi di lavoro manualmente.

I seguenti collegamenti potrebbero essere di interesse.

How the Runtime Locates Assemblies
Best Practices for Loading Assemblies
Shadow Copying Assemblies
Unloading Assemblies - Suzanne Cook

UPDATE Dopo aver letto un po 'di più sulla copia ombra, credo che la ragione si potrebbe vedere la questione delle assemblee bloccati nella cartella extra è che ASP.NET probabilmente specifica solo la cartella "bin" per shadow copying.

Answer 2

1. penso che questo è lo stesso di un'istruzione using in C#, che in pratica significa che le classi del namespace sono ora disponibili per essere utilizzati nella pagina di yoru.
2. L'assemblea verrà caricato nella memoria probabilmente dal processo aspnetwp.exe
3. Se il gruppo è attualmente in uso si ottiene questo messaggio di errore
4. Un riavvio è il modo più sicuro che conosco di fare questo, si potrebbe utilizzare l'iniezione di dipendenza o l'associazione tardiva per ottenere lo stesso risultato. Mi chiedo perché vorresti cambiare un assembly mentre l'applicazione è in esecuzione?