Project inter-dependency in a solution

    General discussion

  • I have a solution with a complex relationship between some of the DLL projects inside it.  I tried to break the assemblies down so that they are as small as possible along logical divisions.  But I'm being forced to rearrange those divisions or merge the projects.  The problem is that types in one assembly are relying on types in another which has types relying on the first assembly.

    In Java, classes are searched for via a class search path.  C# doesn't have a counterpart.  Granted, the two languages are very different.  But maybe C# assemblies could be built via a two-step process.  In Step 1, the compiler simply builds a list of types visible outside the assembly.  Step 2 is the actual compilation.

    Does that make sense to anyone else?  It's different from the way C# projects are compiled now, but it might solve the problem.

    Will Pittenger

    Saturday, April 29, 2017 4:07 AM

All replies

  • Hi Will,

    The only way to avoid the problem of circular references (which is what you're encountering) is to further decouple your dependencies. As far as I know, there is no magic compiler trick to get around that. There should be a way for you to create a 3rd project, such that instead of Project A having to reference Project B and vice versa, you could put the "common" types into Project C, that both A and B can reference. 

    It sounds like you've tried to do that already, but perhaps there is more you could do. Maybe if you can give us a sample of what your interdependencies look like (show some code), then perhaps we could make some suggestions ...

    ~~Bonnie DeWitt [C# MVP]

    Saturday, April 29, 2017 4:03 PM
  • This reminds me of files like ref/System.Collections.cs in the corefx repository. Those files define the public part of an assembly (apparently a "contract assembly") but omit the implementation. I'm not sure how they are actually used in the build system or maintained.

    Tuesday, May 2, 2017 8:06 PM