If possible, commonly used objects should be pushed into common assemblies.
So if what C uses in A doesn't have to be in A but could be in
MyCommonStuff.dll (that knows nothing about A, B or C) then so much the
better. Look seriously at whether or not you can achieve this. But if that's
not possible then a couple of general comments :
1) use interfaces.
If A needs B and B needs C and C needs A, then change it so that C knows
absolutely nothing about A but uses an interface (defined in
MyCommonStuff.dll) that A supports.
2) dynamic loading and object creation
You can write C so that at run time it gets passed a few strings that tell
it you need type "MyNameSpace.MyType" and its in assembly "MyDll_C.dll" The
type supports an interface that C knows about and hey presto it works.
A circular reference definitely means your design needs changing.
HTH,
Adam.
"don H. Lee" <nospam@xxxxxx> wrote in message
news:O5TTJ3icJHA.1532@xxxxxx
Quote:
> Hi newsgroup
>
> I have a little problem in designing my assemblies.
>
> Following situation:
>
> 1. I have 3 Assemblies: Assembly_A, Assembly_B and Assembly_C
> 2. Assembly_A has a Collection of Assembly_C
> 3. Assembly_B has as Collection of Assembly_C
> 4. Assembly_C has a Object of Assembly_A and another one of Assembly_B
>
> So that's the situation and the situation must be like this (relationally)
> because Assembly_A and Assembly_B represent contractors and Assembly_C
> represents the contract. A contract is made between A and B.
>
> Both contractors can have n contracts. A contract has one A and one B.
>
> When trying to build this solution with team build the build process stops
> in case of circular references.
> It is logical, because A cannot be build until C is build and C cannot be
> build until A is build.
>
> Now my question. Is there a desing that don't destry the logic of the
> depencies between the assemblies but don't result in build errors.
>
> If not, what kind of design should I use for cases like this?
>
> Thanks for every suggestions and help!
>
> Best regards
>
> D.H. Lee
>