Organization within "The Repository"

There are two ways of creating Repositories. One way is to create a different repository for each project. That's fine so long as you want to manage multiple repositories… My preference is to have one repository know by me as “The Repository” and to have each project as a directory within the root directory of “The Repository”.

This folder structure needs to be updated to the current methodology.

I have tried to standardize the directory structure of my development projects. Below is a description of the main folders and files within the “trunk” directory where the majority of the development work is done.

This directory contains build artifacts and should never be put under source control. This folder is also used as a staging folder in preparation for MSI generation or deployment of application.

This directory contains sql scripts to create and/or update the database used in the project. This directory may also contain files related to the data in the database such as initial data for lookup tables. It may also have template files related to export of data such as Excel spreadsheets

This directory should be fairly self explanatory, as it contains documentation artifacts related to the project. These can be things like stories, diagrams, user manuals, build guides, installation guides, user guides, etc.

This directory contains all of the third party libraries that will be needed to be deployed with the application. Keep in mind that 3rd party libraries could also be app specific versions of “in-house” libraries that you share between projects. As my standard, log4net.dll and log4net.xml are included in the project template. log4net is my choice for an application logging framework and I use it in all of my projects. For more information on log4net, see the Log4Net page.

This directory contains all of the code that belong to the project. Under the “src” directory, should be folders that correspond to the namespace of the component being developed

For example, one of my recent projects had 4 components:

• Admin
• Client
• Common
• Server

Each of these folders contain a C# project representing the components within the project. Within these “component” directory, sub-directories represent namespaces. So a folder called “IO” under the PasswordNotification.Common folder would represent the namespace: “PasswordNotification.Common.IO”

There is always one special folder that exists under the component folder called “Tests.” The “Tests” directory contains all of the code that is related to testing the code that will be deployed. Each class in the test folder should be named after the class it is testing plus the word “Tests.” In other words, If you have an “Directory” class, you would have a “DirectoryTests” class in this folder. The namespace hierarchy should be maintained below the “Tests” folder. Using the example from above, A class “PasswordNotification.Common.IO.ConfigFile” would have a corresponding test class “PasswordNotification.Common.Tests.IO.ConfigFile” which be in the IO folder underneath the “Tests” folder.

This directory contains all of the supporting third party libraries and executable files that are there to serve the sole purpose of build automation, testing, documentation, etc. These files are essential during the build process.

Sub-directories that you might expect to find in here are:

• nant
• mbunit/nunit
• rhino
• sandcastle
• wix
• svn
• hhc

Each project contains several files in the root directory of the project. These files serve various functions.

This file tells AnkhSVN (a Visual Studio Plugin for Subversion) to load or not load for this project. This file should not be source controlled since this is a per-developer preference.

This files contains the commands and targets to initiate the NAnt build script. My template comes with a build script that comes with a base set of targets. I then customize the “compile” target to build the project and add a “deploy” or “package” target.

This file is used by WIX to create an MSI file that will install the application on a computer. The file is XML based and the xml elements are very specific to the projects needs.

These files are used by Visual Studio to determine project files and user settings. The .suo file is user options and should not be source controlled. As you can imagine this physical folder structure described in this article does not correlate to what you will see in studio, as unfortunately, studio comes up with its own way to view your world…

This file is there to account for the differences in individual machine configurations without cluttering the build file with knowledge of each specific developers machine in a team environment. Machine specific settings are kept in this file that each developer maintains their own copy of, and the settings in the file get leveraged during the build process to carry out the build automation tasks on each developers machine.

The file stored in source control is a template file. To make use of this file, you would need to copy the template file and remove the “.template” extension. The copied and renamed file should not be checked into the repository since that would affect other developers…

The purpose for having the structure that is outlined above is to have a completely atomic unit for projects. The goal being that someone new to a team, with a fresh install of the .Net framework (not even Visual Studio), should be able to check out the above project, make the appropriate machine specific changes to the local.properties.xml file, and run build.bat to compile and test the application. The build script can also be executed on a “build” server that does not have any of the developer tools on it. This makes sure that the build process is reproducible on any machine and will produce the exact same result regardless of which developer runs the script.