dirs.proj是如何使用的

本文关键字：何使用 proj dirs | 更新日期: 2024-09-24 01:17:40

恐怕我问了一个非常愚蠢的问题，但我似乎找不到任何能说明这一点的东西。我通常处理较小的应用程序，但现在正在处理一个较大的应用程序。该应用程序在基线框架中有几个程序集，在产品线域中有多个程序集（还有更多）。我希望通过配置MSBuild来管理生成。我做了很多在线研究（特别是我发现的几篇MSDN文章），现在我觉得知识渊博，很危险。

我知道在csharp中，可以卸载*.csproj文件，并使用属性、项和目标对其进行修改，以控制构建过程。我也知道我可以导入自己的目标文件来帮助分离和组织。不过在这个链接中(https://msdn.microsoft.com/en-us/magazine/dd483291.aspx)多级项目构建使用节点级dirs.proj文件进行组织。这让我感到困惑，并提出了几个我似乎找不到答案的问题：

  1. *.proj和*.csproj文件有什么区别
  2. 可以在VS中设置*.proj以在使用F6的Build上加载吗？或者使用它只需要使用命令提示符吗？（即"msbuild dirs.proj/t:Build"）
  3. dirs.proj是否自动加载？如果是这样的话，我的学习方式是不正确的，但它是在命令提示下进行的
  4. 还是我忽略了"dirs.proj"，也许它只是一个项目*.csproj文件的替代名称？如果是这样的话，就不需要根节点的dirs.proj了，据我所知，它没有与之相关的实际项目

无论如何，我在几个论坛上看到过dirs.proj提到的问题，但我在哪里都找不到它是如何在VS中加载或使用的（除了手动命令提示符构建之外，如果用它来组织构建，这似乎是不合理的，但构建并不会花太多时间）。我希望有人能帮我实现这一时刻。

提前谢谢。

dirs.proj是如何使用的

Dirs.proj是一种MSBuild约定，通常用于处理非常大的源树（>20个以上的项目）。我曾与前一家公司的微软工程师合作过，dirs.proj约定似乎是微软开发并在内部用于管理非常大的源树的约定。

一个很好的实现参考是CodePlexGitHub上的Python Tools for Visual Studio项目。

Sayed Ibrahim Sashimi分享的链接很好地解释了msbuild范式背后的推理，但它并没有很好地展示它如何工作的实际例子。Python Tools项目就是一个很好的参考。

使用这种范式的想法很简单。我敢打赌，大多数.NET软件工程师从事的项目规模有限，一次处理的项目不超过5-10个，他们通过解决方案（.sln）文件在Visual Studio中管理这些项目。他们甚至可能指示他们的构建系统在.sln上运行构建。这很好，直到你开始考虑将产品扩展到更大的平台或将其与更大的产品组合，例如一个有很多项目的平台。解决方案文件不是MSBuild文件，因此它们不像MSBuild那样具有可扩展性，并且在处理大量项目时会遭受巨大的性能损失。

从MSBuild的角度来看，dirs.proj代表VisualStudio.sln文件。然而，不同之处在于，dirs.proj不像.sln那样只包括.csproj（等等），相反，它们可以包括源子树（例如其他嵌套的dir.proj）。因此，构建根目录.proj可以导致整个源树的构建，或者构建嵌套的目录s.proj将导致该子树的构建。

因此，该范式鼓励您将源代码视为一系列相互依存的节点，这些节点被组织到功能或产品领域中。这样，工程师就可以在非常大的项目中处理不同的源子树，而不必像VS解决方案那样处理整个源树。

使用这种模式还带来了.sln文件所没有的某些好处。例如，如果一个项目引用了另一个独立子树中的项目，msbuild将首先自动生成该引用。此外，源节点可以携带自己的构建设置，允许根据构建场景使用不同的构建设置动态构建它们。例如，在一种情况下，SharePoint源子树需要WSP打包，C#子树需要在没有.pdb的情况下构建，DB子树需要生成dacpac，整个源树需要使用myCorp.snk对其程序集进行签名，并将构建输出设置为$（buildRoot）''output目录。

dirs.proj不是通过visualstudio打开的，而是使用msbuild在命令行上构建的。唯一的痛点是这些文件必须手工整理。

因此，长话短说，看看Python Tools项目，看看他们是如何使用dirs.proj的。注意整个源树是如何具有由common.Build.settings管理的公共设置的，以及这个.settings文件中的msbuild属性是如何在各种.csproj文件中使用的。

相关文章：