tags:

views:

6

answers:

0

The projects are broken down in most cases to 4 sub-projects

  • Common mostly dependency free code
  • Control the user control or dialogs for this component/feature
  • Service the code to fetch from the db or mainframe
  • Test - any tests written

Many of these little 4 sub-project features/components have dependencies on other components but those dependencies are managed via most controls being built locally and copied to a userControl folder. So the hint paths point there on the project files. ..\..\..\..\..\RmiUserControls. Note that although it says user controls there is plenty of code that gets sent there that isn't a control =(.

3rd party libraries get their own separate centrally located folder.

So the overall structure is a tree:

  • Branch (which release)
    • Build Process
      • BuildScripts folder
    • Source
      • 3rd party controls
      • 3rd party referenced assemblies
      • RmiUserControls - where most things get copied to after build (not directly built to)
      • AppName
        • Core - common code and shell for hosting the 3 main modules
        • Main module 1
          • Common
          • CommonControls - mostly controls that other controls are likely to be dependent on
            • Featureset/screen folder
              • ComponentName.Common
              • ComponentName.Control
              • ComponentName.Service
              • ComponentName.UnitTest
          • IndividualControls
        • Main Module 2, etc...
Project files are not at a consistent depth.

Because of inter-dependencies (that do not directly reference the other project) there is a lot of hand-crafted build script spaghetti code.

there is no solution file that would build the entire app.

My approach has been to attempt to use linq to xml on the 443 .csproj files to generate a new .proj msbuild script that builds in the correct order

Is there a simple solution to this mess?