I typically work in a consulting capacity and work on a lot of projects. Because of this, I am continually reorganizing projects and adding open source projects to aid in development. I finally decided it was time to document this directory structure so I don't have to pull it from memory with every project.
Project
- Documentation
- Source
- Build
- dist
- docs
- src
- project.build
- project.properties.xml
- Documentation
- Company.Suite.Project
- Private Assemblies
- Company.Suite.Project.csproj
- Company.Suite.Project.Test
- Private Assemblies
- Company.Suite.Project.Test.csproj
- Company.Suite.Project.Web
- Private Assemblies
- Company.Suite.Project.Web.csproj
- web.config
- Company.Suite.Project.Web.Services
- Private Assemblies
- Company.Suite.Project.Web.Services.csproj
- web.config
- Company.Suite.Project.Windows
- Private Assemblies
- app.config
- Company.Suite.Project.Windows.csproj
- build.bat
- deploy-dev.bat
- deploy-test.bat
- Project (Solution).fxcop
- Project (Solution).ndoc
- Project (Solution).nunit
- Project (Solution).sln
[ Oct 5, 2005 ]
One thing I'm wondering about is whether to use the NDoc project file or not. I like having it separate; but it looks like there might be problems with getting the build directory to be where I want it - it uses relative paths to the working directory and I want relative to the .ndoc file. The only way to get around this, as far as I can see is to not use the NDoc project file and have those settings in the build script. This may cause problems in the future if/when the file needs to be updated for a new version. Perhaps an XSL file could be used to transform it to the NDoc format. Oh, and there is one other thing... a small script could be written to copy the .ndoc settings to a build script. This may actually be a happy medium. I'll have to play with it.