Cómo evitar que ASP.NET cargue todos los ensamblados desde el bin en la primera carga

Question

Una aplicación DotNet nativa cargará todos los ensamblados referenciados (y sus referencias) en el primer uso. Sin embargo, un ASP.NET cargará todos los ensamblados referenciados (y sus referencias) en el primer acceso.

1. ¿Es correcto este entendimiento?

2. ¿Hay alguna manera de obligar a ASP.NET a cargar montajes bajo demanda (como aplicaciones locales)?

3. El escenario específico que estoy tratando de resolver es:

   • La carpeta bin contiene 2 archivos: A.dll y B.dll.
   • A.dll referencias B.dll.
   • B.dll referencias C.dll que está en otro lugar en el sistema. En este caso, falta C.dll.
   • A.dll se carga (usando reflejo) por la aplicación principal.
   • El error encontrado (no se pudo cargar el archivo o ensamblado ...) se relaciona con una dependencia faltante de B.dll.
   • Queremos que la aplicación funcione normalmente si C.dll falta porque este es un componente opcional de la aplicación principal.
   • No tenemos control sobre los contenidos de B.dll o C.dll.

Answer 1

cargas ASP.NET todos los montajes necesarios debido a que el proceso de trabajo crea un dominio de aplicación con todos los conjuntos requeridos para cada caso.

si desea cargar ensamblajes bajo demanda intente usar el reflejo de esa manera puede controlar qué y cuándo cargar sus ensamblajes.

** edit: **

si imposible tener control sobre B y C, pero usted está diciendo que B necesita para ejecutar C, y A tiene una referencia difícil de B. me parece que usted necesita Para que funcionen los componentes ABC, puedes intentar eliminar la dependencia B de A haciéndolo un par flojo.

puede usar la reflexión para cargar B desde A pero todavía es necesario que C siga causando problemas.

¿cómo se compila su solución sin el componente C?

¿C está almacenado en el GAC?

Answer 2

Para responder al punto 3, la configuración que hace que todos los ensamblados de la carpeta bin se carguen en el primer acceso se puede encontrar en el archivo C: \ winnt \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG \ web.config (dependiendo de su entorno). Corte hacia abajo extracto de ese archivo:

<system.web> 
    <compilation> 
     <assemblies> 
      <add assembly="*" /> 
     </assemblies> 
    </compilation> 
</system.web> 

Todos los conjuntos que coinciden con el comodín se cargan como parte de la compilación inicial.

Modificando el web.config de la aplicación (NO la DotNet mundial uno) para incluir el conjunto de servicios web y excluir el partido de comodín, parece que la aplicación puede funcionar si las dependencias opcionales faltan:

<system.web> 
    <compilation> 
     <assemblies> 
      <remove assembly="*" /> 
      <add assembly="Main.Application.WebService, Version=1.0.0.0, Culture=neutral, PublicKeyToken=YOURKEYHERE" /> 
     </assemblies> 
    </compilation> 
</system.web> 

Todavía estamos experimentando con esto, por lo que no estamos seguros de si esto resuelve completamente el problema o si tiene algún efecto secundario inusual.