Circular DLL dependencies in .NET

Question

I have a DLL which provides an entry point to an ASP.MVC application. Let's call this Primary.DLL. In Primary.DLL, there are LINQ-to-SQL data context and other classes defined. Somewhere in Application_Start(), Assembly.Load() is called to load Secondary.DLL. Secondary is NOT referenced in Primary.DLL's project file. But Primary is referenced in the project file of Secondary.DLL because the LINQ-to-SQL data context and other classes mentioned above are used in Secondary.

Would this create a circular dependency problem? Would there be any problem with this kind of design?

Incidentally, since circular dependencies work if you somehow fool the compiler into generating them, this cannot be a problem. — Joshua, Jan 16 '12 at 03:18

score 1 · Answer 1 · answered Jan 16 '12 at 02:28

1

Assemblies do not get reloaded into an AppDomain, and you are only loading Secondary.dll within Application_Start so this should not cause any problems and would also not result in any manifestation of a circular dependency.

answered Jan 16 '12 at 02:28

Ethan Cabiac

4,943
20
36

score 1 · Answer 2 · answered Jan 16 '12 at 02:29

1

It won't create a circular dependency problem, but it may not be a great design. Circular dependencies require an actual reference between two or more projects.

answered Jan 16 '12 at 02:29

Chris Shain

50,833
6
93
125

score 1 · Accepted Answer · answered Jan 16 '12 at 03:10

1

We do this all of the time with customer-specific customization DLLs. We use the same functionality in web applications, services, and desktop exes.

The customer DLLs reference the base project DLLs so that they can inherit from various classes and implement interfaces. To do so, they must have a reference to the base dll.

At application startup (global.asax Application_Start or an exe's initialization routine), we load any discovered customization DLLs through Assembly.Load and it definitely does not create a cross-reference.

answered Jan 16 '12 at 03:10

competent_tech

44,465
11
90
113

This is the exact customization that I'm trying to do. The "contract" classes and interfaces are well defined, but the implementation will vary year after year. Future DLLs are discovered at run-time, but to build (compile) them, they have to reference some classes and interfaces defined in the base DLL. – Kevin Le - Khnle Jan 16 '12 at 04:06

Circular DLL dependencies in .NET

3 Answers3