为什么要在 dotnet 发布之前使用 dotnet 构建？答案

【问题标题】：Why bother with dotnet build before dotnet publish?为什么要在 dotnet 发布之前使用 dotnet 构建？
【发布时间】：2019-09-07 21:16:22
【问题描述】：

很好。这似乎是我看到答案时会面面相觑的问题类型。

所以...

为什么要在dotnet publish 之前打扰dotnet build？

build 自动执行restore。凉爽的。

似乎publish 做了一个build（除非你告诉它不要这样做）。所以...如果您要在之后发布，为什么还要麻烦构建？为什么不直接发布，一切都在一步完成？

为了更清楚...

我在一个基本场景中询问：

与只是

他们似乎做同样的事情。

【问题讨论】：

我不会直接回答你的问题，如果有区别的话，我会把它留给知道区别的人。但是，如果您有 1 个执行 17 件事情的命令，并且您有 17 个执行 1 件事情的其他命令，那么一次执行一个执行这 17 个命令会为您提供更好的处理问题的机会，因为只有少数问题您需要处理这 17 个命令中的每一个，而执行 17 件事情的 1 个命令可能会出现 17 个问题。
（意见）但是，知道这是由 Microsoft 构建的，可能会有一些重大差异，例如 nuget 包。使用 nuget 包，您有 nuget install、nuget restore、dotnet restore 和 msbuild /t:restore;xxx，它们似乎都做了不同的事情，您可能需要其中一些才能使构建继续进行。所以谁能说出来。如果dotnet publish 做你想做的事，我会说不管文档告诉你什么，去吧。
请注意：如果您执行 dotnet publish --no-restore，那么 publish 不会构建，因此您需要构建步骤。

【解决方案1】：

dotnet publish 自动执行 dotnet build 已经执行的所有操作是对的。在大多数情况下 - 如问题中提到的场景 - 这意味着不需要额外的 dotnet build。

请注意，您可以dotnet build 解决方案，但只能dotnet publish 单个项目文件。发布解决方案可能会导致意想不到的结果（从覆盖不同版本的文件到在不应发布到与引用应用程序相同的输出目录的配置中发布库项目等）

随着时间的推移，有一个社区要求在不重新构建应用程序的情况下允许发布和测试，因为一些用户觉得只发布具有相同二进制文件的应用程序更舒服，因此他们的构建脚本看起来像：

【讨论】：

有没有办法在 MSBuild 级别使用 MSBuild /t:Publish --no-build 或等效项？我在 MSBuild 命令行文档中没有看到 --no-build 参数。我直接在我的 csproj 文件上调用 MSbuild，并希望将发布和构建操作分开。