What is a good Visual studio source code layout for cross-project inheritance hierarchies

Question

I develop similar calculation packages for different clients (Bob, Rick, Sue, Eve). The calculation packages consist of several calculation modules (A, B, C, D, ...), which are organized in a "Chain of responsibility" pattern. Assembly is done with Abstract factory. As a lot of code is shared between the calculation modules of different clients, they are organized in an hierarchy:

                 ICalcA
                   |
               AbstrCalcA
               |       |
   AbstrCalcAMale      AbstrCalcAFemale
    |         |           |         |
CalcABob   CalcARick   CalcASue   CalcAEve

(same hierarchy for B, C, D, ...).

Now release management dictates, that I organize the source code per inheritance level:

Project: CalcCommon
  [CalcA]
    ICalcA.cs
    AbstrCalcA.cs
  [CalcB]
    ICalcB.cs
    AbstrCalcB.cs
  [CalcC]
    ...

Project: CalcMale
  [CalcA]
    AbstrCalcAMale.cs
  [CalcB]
    AbstrCalcBMale.cs
  [CalcC]
    ....

Project: CalcBob
  [CalcA]
    CalcABob.cs
  [CalcB]
    CalcBBob.cs
  [CalcC]
    ....

Project: CalcFemale
   ....

For Bob, I release CommonCalc.dll, CalcMale.dll and CalcBob.dll.

Now this is all good, but with many modules, helper classes, and so on, it is very cumbersome to work within the same module hierarchy. Closely related classes (e.g. ICalcA and CalcABob) are far away in the solution explorer. No one on my teams seems to find anything without searching for the class name -- if he can remember it. Features tend to get implemented in wrong or multiple hierarchy levels.

How can I improve the situation?

I was thinking of creating one project per Module and hierarchy level (Projects: CalcCommonA, CalcMaleA, CalcBobA, CalcRickA, CalcCommonB, CalcMaleB, ...), and grouping them via solution folders.

Answer 1

I just found out that the new search bar on top of the solution explorer comes in handy for this.

Step 1: Make sure all classes related to Feature A contain "FeatureA" in their class name.

Step 2: If working in the FeatureA hierarchy, enter "FeatureA" into the search/filter bar.

This will display just to the classes of this particular hierarchy, just as required.