【问题标题】:How is dirs.proj used?dirs.proj 是如何使用的?
【发布时间】:2015-05-04 03:46:33
【问题描述】:

恐怕我问的是一个非常愚蠢的问题,但我似乎找不到任何可以说明这一点的东西。我通常处理较小的应用程序,但现在正在处理一个较大的应用程序,其中包含基线框架中的多个程序集和产品线域的多个程序集(未来还会有更多程序集)。我想通过配置 MSBuild 来管理构建。我做了很多在线研究(特别是我发现的几篇 MSDN 文章),现在我觉得知识渊博到危险的程度。

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

  1. *.proj 和 *.csproj 文件有什么区别?
  2. 可以在 VS 中设置 *.proj 以在使用 F6 构建时加载,还是仅需要使用命令提示符? (即“msbuild dirs.proj /t:Build”)。
  3. dirs.proj 会自动加载吗?如果是这样,我的 study-by 工作不正常,但它在命令提示符下工作。
  4. 或者我是否忽略了“dirs.proj”的某些内容,也许它只是项目 *.csproj 文件之一的替代名称?如果是这种情况,尽管不需要根节点的 dirs.proj ,据我所知,它没有与之关联的实际项目。

无论如何,我已经在几个论坛中看到有关问题的 dirs.proj,但是我在哪里可以找到它是如何在 VS 中加载或使用的(在手动命令提示符构建之外,如果用于组织构建,这似乎是不合理的但构建不会真正花费大量时间)。我希望有人可以帮助我实现这一点。

提前致谢。

【问题讨论】:

  • 没有根本区别,因为它们只是 msbuild 文件。 visual studio 查看某些元数据/属性并确定如何加载它。
  • 那你如何将它集成或设置它与 VS 解决方案来构建?那么“dirs.proj”是否只是配置大型构建的“源树”方法的常用命名法?
  • 这取决于它包含的内容。
  • 嗯...使用项目模板?我会试一试,然后告诉你。

标签: c# visual-studio-2013 msbuild


【解决方案1】:

Dirs.proj 是一种 MSBuild 约定,通常在处理非常大的源代码树(> 20 个项目)时使用。我曾在前一家公司与微软工程师一起工作,dirs.proj 约定似乎是微软开发并在内部用于管理非常大的源代码树的约定。

CodePlex 上的 Python Tools for Visual Studio 项目是一个非常好的实现参考。

link you shared by Sayed Ibrahim Sashimi 很好地解释了 msbuild 范式背后的推理,但它并不能很好地展示其工作原理的实际示例。 Python Tools 项目是一个很好的参考。

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

从 MSBuild 的角度来看,dirs.proj 代表 Visual Studio .sln 文件。然而,不同之处在于 dirs.proj 不仅仅像 .sln 那样包含 .csproj(等等),而是可以包含 源子树(例如其他嵌套的 dirs.proj)。因此,构建根 dirs.proj 可能会导致构建整个源代码树,或者构建嵌套的 dirs.proj 会导致构建该子树。

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

使用此范例还具有 .sln 文件所没有的某些好处。例如,如果一个项目从另一个单独的子树中引用一个项目,msbuild 将首先自动构建该引用。此外,您的源节点可以携带自己的构建设置,允许它们根据构建场景使用不同的构建设置动态构建。例如,在一种情况下,SharePoint 源子树需要 WSP 打包,C# 子树需要在没有 .pdb 的情况下构建,DB 子树需要生成 dacpacs,整个源树需要使用 myCorp.snk 对其程序集进行签名并设置构建输出到 $(buildRoot)\Output 目录。

dirs.proj 不是通过 Visual Studio 打开的——它们是使用 msbuild 在命令行上构建的。唯一的痛点是文件必须手动整理。

所以,长篇大论,看看 Python 工具项目,看看他们是如何使用 dirs.proj 的。请注意整个源代码树如何具有由 Common.Build.settings 管理的通用设置,以及此 .settings 文件中的 msbuild 属性如何在各种 .csproj 文件中使用。

【讨论】:

  • 我的项目有一个packages.proj,一个solutions.proj 和一个dirs.proj 伴随着这个,还有一个App.sln。如果我从这里进入解决方案文件夹的一层,有一个 AppSolution.csproj 我对构建顺序应该是什么感到困惑。通常,我先做 Solution.proj,然后再做 packages.proj/。不确定 dirs.proj 在这个顺序中的位置。
猜你喜欢
  • 2016-11-05
  • 2014-07-13
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多