我担心我可能会问一个非常愚蠢的问题，但我似乎无法找到任何能说明问题的东西。我通常在较小的应用程序上工作，但现在我正在开发一个更大的应用程序，在基线框架中有几个程序集，而产品线域有几个程序集（还有更多）。我想通过配置MSBuild来管理构建。我做了很多在线研究（特别是我发现的几篇MSDN文章），现在感觉知识足够危险。
据我所知，在csharp中，可以使用属性，项和目标卸载和修改* .csproj文件，以控制构建过程。我也明白我可以导入自己的目标文件来帮助分离和组织。在这个链接虽然（https://msdn.microsoft.com/en-us/magazine/dd483291.aspx）使用节点级dirs.proj文件组织多级项目构建。这让我感到困惑，并提出了几个我似乎无法找到答案的问题：
- * .proj和* .csproj文件有什么区别？
- 是否可以在VS中设置* .proj以使用F6加载Build或使用此命令仅需要使用命令提示符？ （即“msbuild dirs.proj / t：Build”）。
- dirs.proj会自动加载吗？如果是这样，我的研究工作不正常，但它与命令提示符。
- 或者我用“dirs.proj”忽略了一些东西。也许它只是一个项目* .csproj文件的替代名称？如果是这种情况，虽然根本不需要根节点的dirs.proj，我可以告诉它没有与之关联的实际项目。
无论如何，我已经看到dirs.proj在几个论坛中提到有关问题，但没有我在哪里可以找到它是如何在VS中加载或使用的（在手动命令提示符构建之外，如果这用于组织构建但是构建似乎是不合理的不会真的花费大量的时间）。我希望有人能帮助我实现这一目标。
提前致谢。
Dirs.proj是一种MSBuild约定，通常在处理非常大的源树（> 20个项目）时使用。我曾在以前的公司与微软的工程师合作过，dirs.proj约定似乎是微软开发并在内部用来管理非常大的源代码树的。
一个非常好的实现参考是 适用于Visual Studio的Python工具 CodePlex上的项目。
该 链接由Sayed Ibrahim Sashimi分享 这是对msbuild范例背后的推理的一个非常好的解释，但它并没有很好地展示它如何工作的实际例子。 Python Tools项目是一个很好的参考。
使用这种范例背后的想法很简单。我猜是大多数.NET软件工程师都在一些有限规模的项目中工作，这些项目一次不涉及超过5-10个项目，他们通过Solution（.sln）文件在Visual Studio中管理这些项目。他们甚至可以指示他们的构建系统在.sln上运行构建。这种方法很好，直到您开始考虑将产品扩展到或将其与更大的产品组合，例如具有许多项目的平台。解决方案文件不是MSBuild文件，因此它们不像MSBuild那样可扩展，并且在处理大量项目时会遭受巨大的性能损失。
从MSBuild的角度来看，dirs.proj代表Visual Studio .sln文件。然而，差异在于，dirs.proj不仅仅包含.ssproj（等等），而是包含.sln，而不是 源子树 （例如其他嵌套的dirs.proj）。因此，构建root dirs.proj可能会导致构建整个源树，或者构建嵌套的dirs.proj将导致构建该子树。
因此，范例鼓励您将源视为一系列组成功能或产品区域的相互依赖的节点。这样，工程师可以在非常大的项目中处理不同的源子树，而无需处理整个源代码树，就像使用VS解决方案一样。
使用此范例还具有.sln文件未附带的某些好处。例如，如果一个项目从另一个项目引用一个项目，那么msbuild将自动构建该引用。此外，您的源节点可以携带自己的构建设置，允许使用基于构建方案的不同构建设置动态构建它们。例如，在一种情况下，SharePoint源子树需要WSP打包，C＃子树需要在没有.pdb的情况下构建，数据库子树需要生成dacpac，整个源树需要使用myCorp.snk签署其程序集并设置构建输出到$（buildRoot）\ Output目录。
dirs.proj不是通过visual studio打开的 - 它们是使用msbuild在命令行上构建的。唯一的痛点是文件必须手工策划。
所以，简短回答看看Python Tools项目，看看他们是如何使用dirs.proj的。请注意整个源树如何具有Common.Build.settings管理的常用设置，以及如何在各种.csproj文件中使用此.settings文件中的msbuild属性。