关于Visual Studio：最佳VSTF源结构是什么？有没有最佳做法？

What is the optimal VSTF source structure? Are there any best practices?

还有许多与此主题相关的其他问题：

对于php应用程序来说，什么是好的标准代码布局(已删除)

换句话说，如何构造Java应用程序：将类放在哪里？

推荐的源代码管理目录结构？

版本控制中的项目结构

我找不到特定于VSTF的任何东西，它具有某些功能，例如团队建设，集成的单元测试等。我想知道这些功能是否导致对源布局的建议稍有不同。

请张贴您幸运的高级目录结构示例，并解释为什么您喜欢它们。我将让人们对"最佳"方法进行投票，并在几天之内给予答案。

一些想法：

树根中的文件很少。在大型团队中，设置权限，以便没有任何类型的授权，任何人都无法将新文件添加到树的根目录中。

默认工作空间将包含：

工具包含构建和运行单元测试所需的所有可执行代码，包括自定义工具和脚本(可能假设计算机上已安装了Visual Studio和PowerShell)。
ReferencedAssemblies具有您从其他地方获取的东西，包括您购买或下载的东西以及团队中某人写的东西，但不属于该项目。
- 如果可用，源代码也应位于此处，以便您自己提供服务。 (如果没有的话，您将承担很大的风险。)
源代码-所有源代码，包括项目文件。
文档-那些项目不用作构建的一部分，但对于开发工作的正常运行是必需的。
二进制-已交付给客户的位，包括.PDB和其他维修所需的工件。 (在小型项目中，我会为每个发行版提供源代码，但是通常使用标签/标签是更好的选择。)

在其他地方(例如$ / personal)有一个供每个人随意处理的地方($ / personal / USERNAME)。例如，我的辅助项目在这里。

这是我喜欢的一个：

私人的;当前所有系统可交付成果
- 文件；将组成该产品的解决方案中的所有文档汇总在一起，输出将是Sandcastle的MSDN样式文档
- 共同; Visual Studio SLN包含所有其他解决方案中共有的所有项目。
- 工具； Visual Studio SLN包含其输出是工具的所有项目。示例可能是在较大系统上执行一组管理任务的控制台应用程序
- 开发人员；每个开发人员都有自己的文件夹，他们可以使用该文件夹存储所需的内容
  - 特定开发人员(1..n)；它包含该特定开发人员选择存储在源代码管理系统中的所有构建设置，脚本和工具(他们可以在此处执行所需的任何操作)
- 特定的可交付解决方案(1..n)； Visual Studio SLN包含特定主要交付项目的所有项目
  - 共同;解决方案文件夹，其中包含在当前解决方案中共享的Visual Studio项目
  - UI；解决方案文件夹，其中包含定义用户体验的Visual Studio项目
  - DataLayer;解决方案文件夹，其中包含定义数据访问层的Visual Studio项目
  - 服务;解决方案文件夹，其中包含定义Web服务的Visual Studio项目
  - 工具；解决方案文件夹，其中包含Visual Studio项目，这些项目定义了特定于此可交付项的工具(可执行实用程序)
  - 测试；解决方案文件夹，其中包含包含单元测试的Visual Studio项目
上市;与系统关联的所有外部依赖项(例如，第三方库)
- 供应商特定供应商提供的依赖项
建立; Visual Studio SLN包含与项目的生成相关的代码，在我们的案例中，大多数是自定义MSBuild任务和Powershell脚本
目标;产品的每次成功构建以及发布的要点
- 调试；从每周构建和持续集成中输出的所有调试构建。开发人员不手动管理此目录
  - 内部编号；与当前内部版本号对应的目录
    - 解决方案输出；一个目录，其中包含给定解决方案中每个项目的所有构建输出
- 发布;达到里程碑后，将手动输出的所有发行版本
  - 内部编号；与当前内部版本号对应的目录
    - 解决方案输出；一个目录，其中包含给定解决方案中每个项目的所有构建输出