How do I organize .NET solutions, projects, and system folders for multiple applications?

We are having a lot of trouble organizing our solutions in a good way. We have multiple applications. They are similar applications so a lot of reuse is done. Different apps include different capability depending on what our different customers will pay for.

So, how do we go about organizing things? MSDN says to organize in the following way:

SolutionFolder\
               Proj1Folder\
               Proj2Folder\
               Proj3Folder\ ...

(Note: By solution folder, I mean an actual folder on the system, not a visual studio solution folder.)

But no details are mentioned regarding multiple solutions that reuse projects. It wouldn't make sense to create a second solution folder and reference projects under the first solution folder. My first thought is to completely isolate the solutions and then reference the projects as needed. Does that make sense? See below:

Solutions\
          Solution1.sln
          Solution2.sln
          Solution3.sln
Projects\
         AFeatures\
                   AProject1\
                   AProject2\
                   AProject3\
         BFeatures\
                   BProject1\
                   BProject2\
         CFeatures\
                   CProject1\
                   CProject2\

In the example above, I've grouped the projects based on certain features. Solution1 may include features A and C, Solution2 may include features B and C, and Solution3 may include A and B. Things get more complicated because each feature can have sub-features that won't be in all solutions. In other words, there may be common AFeatures but then a more specific A-1Features, A-2Features, etc.

On top of this, we'd also like to group our projects base on n-tier architecture. So, I imagine we'd add BusinessServices, DataServices, and UserServices folders in the midst too. But, does it make sense to put the n-tier folder above or below the features structure? This is where my brain starts to spin.

On a similar note, we'd like to have our interfaces in differen开发者_StackOverflowt projects that the implementation. This may not be that big of a deal. I imagine we'd have a AInterfacesProject1 and AProject at the same directory level so they're close together.

I'd appreciate anybody's comments on my examples. And, if you've had experience with my same problem, I'd be curious as how you organized it.

All I can tell you is how I organise my projects.

I have an ASP.NET CMS / Framework; this is made up of 3 core solutions:

MyCode.Core (sln)
  \MyCode.Core.Common (proj)
  \MyCode.Core.BusinessLogic
  \MyCode.Core.IDataprovider 
  \etc...

The MyCode.Core sln is the only place I do any (serious) development on these projects. I copy successful builds to a "neutral" location on disk.

Included in this is copies of the dll's these projects reference (MS Ent Libs, AntiXSS library).

Next I have a project which is a sort of SDK for "skins and templates".

MyCode.Templates (sln)
  \MyCode.Templates.Nasqueron (proj)

The output of this project gets copied to the same neutral location as the core. This project references outputs of the MyCode.Core projects - specifically the ones kept in the neutral folder.

Finally I have the web project itself. I let Visual Studio manage this the way it wants to. All references are aganist the dlls copyied to the neutral location.

So basically my approach is:

• Only allow projects to be edited within the scope of one solution (basically - decide on who "owns" the project).
• copy / deploy stable copies to a neutral location that sits outside of the actual solution / project file structure, and reference these copies of the shared code.