¿Qué sucede cuando cargo un ensamblaje?

Question

En mi aplicación ASP.NET MVC, que tienen la siguiente configuración:

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

he referenciado asambleas ubicados en la carpeta extras en los puntos de vista y han funcionado a la perfección (usando <%@ Import Namespace="myNameSpace" %>).

Mis preguntas

1. lo que sucede cuando se llama esa línea?
2. ¿Dónde se carga el conjunto?
3. ¿Por qué no puedo sobrescribir el conjunto ubicado en la carpeta extras que contiene myNameSpace con una versión más nueva? (Recibo un error que dice que el ensamblaje está "abierto" en otro programa)
4. ¿Hay alguna manera de sobrescribir el ensamblaje con una versión más nueva sin tener que reiniciar la aplicación?

Answer 1

1) La importación en realidad no hace nada en el tiempo de ejecución. Es una conveniencia en tiempo de compilación que simplemente le permite consultar tipos utilizando sus nombres no calificados, como Environment en lugar de System.Environment.

2) El ensamblaje se carga utilizando las reglas normales de prueba de ensamblaje. El CLR comprueba varias ubicaciones antes de estas rutas de exploración privadas, por lo que es importante tener esto en cuenta. Si hace referencia a un ensamblado de nombre seguro y espera encontrar ese ensamblaje en una ruta de exploración privada, se preferiría un ensamblado con el mismo nombre seguro (nombre, versión, clave pública, etc.) en el GAC. Esto a veces puede llevar a un comportamiento inesperado y generalmente es causado por una codificación dura de una versión de ensamblaje en su AssemblyInfo.cs y olvidando actualizarlo.

3) Una vez cargado, un ensamblaje no se puede descargar sin descargar el AppDomain. Pero ASP.NET utiliza "copia oculta", lo que significa que los ensamblajes se copian en una ruta temporal antes de cargarse. Esto debería dejar el ensamblaje original desbloqueado y poder sobrescribirlo. Fuera de mi cabeza, no estoy seguro de por qué recibirías el error sobre los ensamblajes bloqueados. En una aplicación normal de Windows, esto sería totalmente normal y esperado. Pero ASP.NET está diseñado para que pueda sobrescribir el contenido, el código, los ensamblajes, etc., mientras se ejecuta la aplicación, lo que lleva al # 4.

4) En la práctica, no. Debido a que un ensamblaje no se puede descargar, no hay forma de actualizar un ensamblaje sin reiniciar la aplicación web. Técnicamente hablando, puede cargar múltiples versiones de un conjunto, pero esto no le daría los resultados deseados. Todas las referencias en tiempo de compilación seguirían haciendo referencia al ensamblaje anterior y obtendría todo tipo de excepciones de conversión no válidas si intentara usar el nuevo ensamblado. Pero como dije en el n. ° 3, con ASP.Se supone que los ensamblados de actualización de NET son tan simples como reemplazar los archivos y deberían suceder automáticamente. No debería tener que reiniciar IIS o procesos de trabajo manualmente.

Los siguientes enlaces pueden ser de interés.

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

ACTUALIZACIÓN Después de leer un poco más acerca de la copia sombra, creo que la razón por la que puede estar viendo el tema de asambleas encerrados en la carpeta extras es que ASP.NET probablemente solo especifique la carpeta "bin" para shadow copying.

Answer 2

1. creo que esto es lo mismo que una instrucción using en C#, que básicamente significa que las clases del espacio de nombres ya están disponibles para ser utilizados en la página yoru.
2. la Asamblea se carga en la memoria, probablemente por el proceso aspnetwp.exe
3. Si el conjunto está siendo utilizado obtendrá este mensaje de error
4. Un reinicio es la forma más segura que conozco de hacer esto, se podía use inyección de dependencia o enlace tardío para lograr el mismo resultado. Me pregunto por qué querrías cambiar un ensamblaje mientras la aplicación se está ejecutando.