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