如何在不检查依赖项的情况下构建 C# 项目？答案

【问题标题】：How to build a C# project without checking dependencies?如何在不检查依赖项的情况下构建 C# 项目？
【发布时间】：2010-08-27 20:21:00
【问题描述】：

给出一个解决方案：

项目 P1 引用了 P2
P2 引用了 P3
P3 引用了 P4

当你以这种方式调用 msbuild 时：

msbuild.exe /v:m "c:\mysolution\p1\p1.csproj"

msbuild 检查所有项目的依赖关系，必要时构建依赖关系。典型的输出是：

Microsoft (R) Build Engine Version 4.0.30319.1
[Microsoft .NET Framework, Version 4.0.30319.1]
Copyright (C) Microsoft Corporation 2007. All rights reserved.

  P4 -> c:\mysolution\P4\bin\Debug\P4.dll
  p3 -> c:\mysolution\p3\bin\Debug\p3.dll
  p2 -> c:\mysolution\p2\bin\Debug\p2.dll
  p1 -> c:\mysolution\p1\bin\Debug\p1.dll

就我而言，我知道存在依赖关系并且一切正常。

有没有办法只构建项目p1.csproj 而无需验证依赖关系？解决方案可以使用 msbuild 或其他东西。

【问题讨论】：

我想知道....我可以调用 c# 编译器而不是 msbuild 并传递所有参数吗？即使对于具有大量引用和依赖项的大型项目，是否也很难弄清楚要传递的参数？
相关问题：stackoverflow.com/questions/819031/…
谢谢。我们已经使用带有 msbuild（/m 选项）的多处理器构建，对我们来说，它有很大的不同：快了近 2 倍。

标签： c# visual-studio msbuild

【解决方案1】：

您可以将/p:BuildProjectReferences=false 传递给 msbuild，这将跳过构建项目参考。但这有一个限制，如果您的解决方案配置和引用项目的配置不匹配，msbuild 将无法解析引用项目的目标输出文件...

这里有一个免费的vs扩展包，你可以下载试试 http://visualstudiogallery.msdn.microsoft.com/98de4058-8dc7-435b-9e01-c0f71dace808

vs 包：Sharp Build Utility

我是这个扩展的作者，我现在的工作也有同样的需求，喜欢这个工具...

本质上，这个扩展可以处理上述情况，它将为你的构建项目文件制作一个影子副本，将所有项目引用更改为 dll 文件引用，并使用影子项目文件启动 msbuild。

【讨论】：

【解决方案2】：

目标是什么（你为什么关心）？

您可以使用程序集引用而不是项目引用（但要注意调试与发布路径的差异）。

【讨论】：

我很在意，因为在一个包含 100 个项目的解决方案中，这一步需要很长时间；比编译我感兴趣的项目多 10 倍的时间。更改解决方案的结构或使用程序集引用对我来说不是很好的选择。
这不是我在我的机器上看到的。如果在我的项目上运行 msbuild，大约需要 30 秒才能确定无事可做。如果我立即再做一次，还需要 30 秒。检查依赖关系的过程需要时间。这就是为什么我想跳过那部分。
我很惊讶性能如此糟糕。您可能想要打开 MSBuild 诊断程序以找出需要这么长时间的原因。最新的检查应该很快，特别是如果事情确实是最新的。 Tools\Options\Projects&Solutions\Build&Run 将 MSBuild 输出详细程度更改为“诊断”，执行 30 秒的操作，并在期间（以及之后搜索）观察输出窗口以找到“慢”操作。
我会检查的。顺便说一句，我的电脑是 6GB 的 Intel i7 和高速硬盘，所以我不认为是硬件问题。

【解决方案3】：

也许您可以使用 Visual Studio 中的配置管理器，取消选中除您要构建的项目之外的所有项目。

【讨论】：

我需要一个无需更改解决方案或项目即可工作的解决方案。我需要这个从命令行工作。
@Sly：为您的解决方案添加单独的配置。您可以从命令行选择要构建的配置。这类似于经典 make 中的目标。例如。有一个配置 Release All, Debug All, Release Subbranch, Debug Subbranch, ...

【解决方案4】：

查看 Microsoft 构建解决方案和项目的最佳实践：

Microsoft Patterns & Practices: Structuring Solutions and Projects

您目前拥有的是一个单一解决方案。这是应尽可能使用的理想情况。但是，对于像您这样的大型解决方案，单一解决方案可能会变得不切实际。

您可能需要考虑对解决方案进行分区，即对依赖树的分区使用单独的解决方案。或者您甚至可以考虑使用所谓的多解决方案。查看链接的文章，了解此类更改的后果和缺点。也许使用更快的硬件可能是更好的选择。

【讨论】：

正如我在对 grefly 的评论中所写，我需要一个无需更改解决方案或项目即可工作的解决方案。
顺便说一下，我们曾经有多种解决方案（几年来），但是当你这样做时，你必须对所有重构工具和“查找引用”和“去定义”说好这是最糟糕的构建时间。
@Sly: 1.) 分区解决方案无需修改现有解决方案和项目即可工作，它只是为分区树的子分支添加解决方案。 2.) 对不起，你不能两者兼得。要使重构和查找引用正常工作，必须加载所有源代码，即您必须使用项目引用。这是尽可能使用单一解决方案的原因之一（主要原因是让您的依赖项始终保持最新并处于当前版本并准备好进行调试）。
我知道，这就是为什么我不寻找需要重新设计我的解决方案和项目的解决方案。我想要的只是在某些非常具体的场景中绕过这个不必要的步骤的“技巧”。
@Sly：告诉编译器不要检查项目的修改的唯一“技巧”是@grefly 提到的，即从配置管理器中的构建中排除项目或使用单独配置。可能后者对您来说是最好的选择，因为它允许您通过单击在配置之间进行切换。

【解决方案5】：

您应该查看一个名为 OpenMake 的产品。我的首席构建工程师告诉我，他们在依赖项检查和构建并行化方面做了很多工作。

OpenMake

【讨论】：