asp.net mvc - Diferencia entre AppDomain.GetAssemblies y BuildManager.GetReferencedAssemblies

asp.net-mvc

Question

Solo quería saber si hay alguna diferencia entre los dos, en el contexto de una aplicación de confianza asp.net mvc 2.

Answer 1

.NET Framework aplaza la carga de ensamblajes en el dominio de aplicación actual hasta que se necesiten. Por ejemplo, si llama a una biblioteca de terceros solo desde SomeMethod (), la DLL de terceros normalmente no se cargará hasta la primera vez que se ejecute SomeMethod ().

AppDomain.GetAssemblies () le ofrece todos los ensamblados que ya se han cargado en el AppDomain actual. BuildManager.GetReferencedAssemblies () devuelve una lista de todos los ensamblados a los que se hace referencia desde Web.config y otros sitios, y carga esos ensamblados en el dominio de aplicación actual.

Aquí hay un ejemplo resuelto de lo anterior.

1. SomeMethod () aún no se ha ejecutado.
2. Llamar a AppDomain.GetAssemblies (), devuelve un conjunto que no incluye ThirdParty.dll.
3. Llame a SomeMethod ().
4. Llamar a AppDomain.GetAssemblies (), devuelve un conjunto que incluye ThirdParty.dll.

En este ejemplo, el CLR aplaza la carga de ThirdParty.dll en el dominio de aplicación actual hasta que sea absolutamente necesario. Y como es necesario para la ejecución de SomeMethod (), es cuando se carga.

Alternativamente:

1. SomeMethod () aún no se ha ejecutado.
2. Llamar a AppDomain.GetAssemblies (), devuelve un conjunto que no incluye ThirdParty.dll.
3. Llamar a BuildManager.GetReferencedAssemblies (), devuelve un conjunto que incluye ThirdParty.dll.
4. Llamar a AppDomain.GetAssemblies (), devuelve un conjunto que incluye ThirdParty.dll.

Aquí, aunque nunca llamó a SomeMethod (), la llamada a BuildManager.GetReferencedAssemblies () cargó la biblioteca de terceros en el dominio de aplicación actual en su nombre.

Por supuesto, todo esto está sujeto a ciertas optimizaciones, etc., pero la idea general es válida.