Note, that I will not explicitly address database management in this structure (folder for the db-create, chained revision-based .cs and .sql upgrade scripts etc), since the XPO manages most part of the complexity here.

Below you will find the folder structure for the root of your version control repository.


  Doc                   - development-related docs
    000 Global          - "Global" contains all
    001 Initialization    guidelines, MSP files,
    002 Project Planning  project scope/chapter etc
    003 Prototyping     - numbered folders form up
    004 Milestone 1.0.0   the simple timeline
  Extension             - extensions are kept and
    CRM                   managed separately. "System"
    E-Forms               distros go into "Resources"
    ConstructionPM        in a binary form
  System -->            - xLim framework
  Prototype             - those are better than UCs
    001 SimpleCAB         and represent excellent
    002 Web IoC           knowledge-base material
    003 DxGridSchema      for new developers.
    004 Workflows

Here’s the generic organization of the “System” folder (that’s the core sources for the specific xLim 2 implementation). The extension projects also have similar structure.


  branch                - development branches, if needed
  distribute            - CC.NET releases into this folder              X.Y.Z.Revision format
  tag             - X.Y.Z.Revision format for every               successful commit (autocreated               by the integration server)
  trunk -->

Note, that it is a good idea to place some restrictions on the trunk folders from the very start (if you are using Subversion). Here are the switches that we normally setup:

  • svn:ignore
  • tsvn:logminsize (20-40 characters is enough)
  • bugtraq:warnifnoissue
  • bugtraq: logregex (it is enough to set “#(\d+)” pattern to make any #BugId number recognizable by both TortoiseSVN and Trac)
  • bugtraq:url (for the purposes of trac integration this points to the tickets path and allows you to open referenced tickets by just clicking on the number in the TortoiseSVN log)


  Help                 - help templates and articles
  Resource             - everything that's needed to build
    Dxperience           fresh check-out on a new machine
    Castle               is here (except .NET SDKs).
    EntLib               The same rule applies to the
    Images               specific extensions as well
  Source                    - that's just the sample. It
    xLim.Client.Core          will described below.
    GlobalAssemblyInfo.cs     - you keep those shared and
    VersionAssemblyInfo.cs      accessible, do not you?
  Test                        - unit tests per project
  Tool                        - some tools that could make
    DeploymentAid               development and maintenance
    NavigationBuilder           more simple and efficient
  xLim.Core.sln             - NAnt build file
  go.cmd                      - simply calls Resource/Nant
  Farmenu.ini                   for the build file

This is how the development checkout copy is usually organized for multiple solutions.

*Working folder (i.e.: E:\Projects\xLim): *

  Docs                        - check-out of the documents
  xLim.ConstructionPM         - check-out of the CPM trunk
  xLim.System                 - check-out of the System trunk
    Build                     - this folder is autocreated

Here’s the simple folder structure for the xLim 2 integration server.


  Logs                        - rolling logs of CC.NET
  xLim.CPM                    - separate folder per solution
  xLim.CRM                      being built
    Artifact                  - CC.NET build artifacts
    Build                     - NAnt works here 
    Distrib                   - integration server creates                  distributions here and adds them                  to the SVN. Normally "Distrib"                  is accessible via secure FTP
      lastversion.txt         - simple, but helps to automate
    State                     - CC.NET state information
    Trunk                     - Working copy
  ccnet.config                - the name speaks for itself

A word on the changes. The development cycle of the main project is separate from its extensions (that’s convenient for medium-sized development projects and teams). Extensions use the “Interface” and “Core” libraries from the main xLim project (those are distributed in a form of packaged APIs and are stored in “Resources” folder in the binary form).

Additionally the integration server could package the extensions in one complete setup file along with the corresponding version of the actual application hosts (Server, Desktop or Web). That’s where Integration:\xLim.System\Distrib[Version] are come in handy.