Dashboard > Castle Project > Castle Project > Project structure standards
  Castle Project Log In   View a printable version of the current page.  
  Project structure standards
Added by Krzysztof Kozmic, last edited by Krzysztof Kozmic on Jan 01, 2010  (view change)
Labels: 
(None)

The following establishes the basis of our project structure standards. Please, be a nice guy and follow this. Also fix all differences in the existing code base.

Directory structure

Repository

In the repository each project has its own subtree (without the 'Castle.' prefix, for example Castle.DynamicProxy is in DynamicProxy subtree.
Subproject like components and facilities are kept in additional subtrees: Components and Facilities respectively not to pollute main tree with too many projects.
Each subtree should have three folders: tags/branches/trunk that have the usual functions. From now on we'll be talking about the trunk.

Local working copy of the trunk

trunk should have the following structure, as presented on the screenshot

  • buildscripts - external (via svn:externals) folder pointing to location of common scripts and files used by all projects (incl. NAnt and NUnit)
  • lib - folder for binary dependencies (both internal and external) required to run the project
  • src - folder for the sourcecode of the project
  • tls - folder for tools required at the development time (like mocking framework etc)
  • main solution file - main solution file used for development of the project. It should follow the naming format: Castle.PROJECTNAME-TARGETFRAMEWORK.sln
  • ClickToBuild.cmd - shell script that runs the default build of the project, that is it compiles the project and generates all the files necessary to run the IDE and compile from the IDE.
  • default.build - dedicated buildscript for the project
  • HowToBuild.txt - file with description of all the buildscript switches used for non default build (for example to build for different frameworks like Silverlight or Mono, to run tests, static analysis, code coverage etc).

The tls and lib folders should have subfolders for each target framework that Castle supports (see below), each holding versions of the tools dedicated to the specific framework.

Folders and files

src folder

  • Castle.PROJECTNAME folder for each project in the solution
  • Castle.PROJECTNAME.Tests folder for each test project in the solution
  • Castle.PROJECTNAME.build file containing build script for each project
  • changes.txt file where the log of changes made in the project is being kept

Project folder

Each project's folder should have the following content:

  • Folders and files with the source code
  • AssemblyInfo.cs file generated by the build script.
  • Castle.PROJECTNAME-TARGETFRAMEWORK.csproj project file
  • Castle.PROJECTNAME.build build file
  • default.build build file
  • NAME.snk strong name key file used to sign the project

All references in .csproj files should be to subfolders of lib and tls pointing to the default framework.

Test Project folder

Each test project's folder should have structure identical to the one outlined above with the following additions:

  • all test fixture classes should be named _SOMETHING_TestCase and exist in file _SOMETHING_TestCase.cs

Target frameworks

Below is the list of currently supported frameworks along with their aliases used in names. The aliases should be used where TARGETFRAMEWORK placeholder appears. Default framework at this moment is .NET 3.5 (sp1)

Framework Name
.NET 2.0 (sp2) net-20
.NET 3.5 (sp1) net-35
Silverlight 2.0 sl-20
Silverlight 3.0 sl-30
Mono 2.4 mono-24
Mono 2.6 mono-26

Site running on a free Atlassian Confluence Community License granted to Castle Project. Evaluate Confluence today.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.5.4 Build:#809 Jun 12, 2007) - Bug/feature request - Contact Administrators