Dependencias de DLL circular en .NET

Question

Tengo un archivo DLL que proporciona un punto de entrada a una aplicación ASP.MVC. Llamemos a este Primary.DLL. En Primary.DLL, hay contexto de datos LINQ-to-SQL y otras clases definidas. En algún lugar en Application_Start(), Assembly.Load() se llama para cargar Secondary.DLL. El secundario NO se referencia en el archivo de proyecto de Primary.DLL. Pero Primary se referencia en el archivo de proyecto de Secondary.DLL porque el contexto de datos LINQ-to-SQL y otras clases mencionadas anteriormente se utilizan en Secundaria.

¿Esto crearía un problema de dependencia circular? ¿Habría algún problema con este tipo de diseño?

Answer 1

Hacemos esto todo el tiempo con archivos DLL de personalización específicos del cliente. Usamos la misma funcionalidad en aplicaciones web, servicios y equipos de escritorio.

Las DLL de cliente hacen referencia a las DLL de proyecto base para que puedan heredar de varias clases e implementar interfaces. Para hacerlo, deben tener una referencia al dll base.

En el inicio de la aplicación (global.asax Application_Start o la rutina de inicialización de un exe), cargamos cualquier DLL de personalización descubierta a través de Assembly.Load y definitivamente no crea una referencia cruzada.

Answer 2

Los ensamblajes no se vuelven a cargar en un Dominio de aplicación, y solo está cargando Secondary.dll dentro de Application_Start, por lo que esto no debería causar ningún problema y tampoco daría lugar a una manifestación de una dependencia circular.

Answer 3

No creará un problema de dependencia circular, pero puede que no sea un gran diseño. Las dependencias circulares requieren una referencia real entre dos o más proyectos.