Solution & Project layout, TFS related but not tfs required
Just want a sanity check on this project layout for use in TFS and just 开发者_如何学JAVAnaming conventions in general.
Can I get a feeling if this layout makes sense for a large solution layout.
If I work on product PROD, and plan to have a common core/framework for logging, exception handling, cacheing and other cross cutting concerns this is how I plan to create my folders/solutions. (only logging given in the example)
/TFS
/TeamProjectCollectionName
/Source
/ProductName
Product.Framework.sln (roll up solution for all “framework components”)
/Framework
Product.Framework.Logging.sln (solution for all logging projects/tests)
/Logging
Product.Framework.Logging.Log.csproj
What you already have is impressive. Below is a screen shot of what i would normally recommend.
- You can read more about the branching strategy here http://tfsbranchingguideiii.codeplex.com/
- Break the structure down in to Build, Database, Source.
- Source: Under source you could have one structure for internal frameworks that you manage the code for and need to be version controlled as you foresee further development on them. You can have a folder called refs to keep all external dll's such as aspose, log4net, mvc, etc. The advantage being, it is very easy provisioning this to your build project. Further you can have sub folders for individual product modules. I have associated the ProductFramework solution to my build definition which creates a single versioned dll that then i use across various other components in my project.
- Database: You can version your database projects here.
- Build: Personally i think it is a good idea to have the solution that the build definition would use available to your developers as well. Under this folder you could have that.
HTH.
Cheers, Tarun
精彩评论