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