My company's program is a large and unwieldy WinForms project that is probably 20+ years old and gone through at least one language change. For some reason, the design schema we use consists of independent dlls for nearly every user control, so we now have around 1300 projects.

We have, for example, Project A. Project A has been referenced in the constructor of nearly everything, as it controls some low-level behavior. Project A references Project B, and shows a form from Project B. Project B then adds Project C, D, E, etc as controls which are children of Project B's form, and of course Project B, C, D, E ALL reference Project A, so I can't strip Project A off of Project B.

Project A is accessed from everywhere, so I can't have Project A use an interface and Project [insert letter] pass an instance of Project B to Project A.

I've tried generating an in-between project that calls up an instance of [insert letter] and returns a generic form or usercontrol, but this didn't really solve my problem. Instead, I ended up with another circular reference.

I have a number of other circles to figure out, too. For example, Project F has UserControl G which calls an instance of Project H.UserControl I, which then calls UserControl J in Project F. While luckily they aren't classes referenced everywhere, some of them are larger and may have instances created in several locations, so I have to be careful about what I change and whether I do something that requires a calling class to create an instance of [insert letter] for it.

I'm wondering what design pattern I can use to get these to compile. How, for example, could Project A interact with Project B, still call up that form, but not have it be a circular reference?