为什么在 dotnet publish 之前要使用 dotnet build？

Question

这似乎是一种会让我看到答案而感到惊讶的问题。

那么...

为什么在执行dotnet publish之前要打dotnet build呢？

build会自动执行restore。很棒。

似乎publish会执行build（除非你告诉它不要这样做）。那么...如果你马上就要发布，为什么还要进行构建呢？为什么不直接发布，一步完成所有操作呢？

进一步理解一下...

我正在询问基本情况下的操作：

• dotnet build -c Release MyProj
• dotnet publish -c Release -o /somedir MyProj

与

• dotnet publish -c Release -o /somedir MyProj

它们似乎执行的是相同的操作。

- Josh

---

我不会直接回答你的问题，我会把这个问题留给那些知道区别的人来回答。然而，如果你有一个命令可以完成17件事情，而你还有17个其他命令可以完成1件事情，逐个执行这17个命令会让你更有可能处理问题，因为每个命令只有少数几个问题需要处理，而那个可以完成17件事情的命令则有可能带来17*少数几个问题。 - Lasse V. Karlsen

（观点）然而，知道这是由微软构建的，可能会有一些重大差异，就像nuget包一样。对于nuget包，您有nuget install，nuget restore，dotnet restore和msbuild /t:restore;xxx，它们似乎都做着不同的事情，您可能需要其中几个才能开始构建。所以谁能说得准呢。如果dotnet publish可以满足您的需求，我会建议忽略文档告诉您的任何内容，直接使用它。 - Lasse V. Karlsen

请注意：如果您执行 dotnet publish --no-restore 命令，则发布不会构建，因此您需要进行构建步骤。 - mslot

@mslot 有没有关于 --no-restore 在 dotnet publish 过程中也禁用构建步骤的文档？ - abhim

@abhim 我没有在任何地方读到过这个。 - mslot

Answer 1

您是正确的，dotnet publish 自动完成了 dotnet build 的所有功能。在大多数情况下 - 就像您在问题中提到的场景一样 - 这意味着不需要额外运行 dotnet build。

请注意，您可以通过 dotnet build 命令构建一个解决方案，但应该只对单个项目文件使用 dotnet publish 命令。构建解决方案可能会导致意想不到的结果（从覆盖不同版本的文件到将库项目发布到与引用应用程序不应发布到的相同输出目录等）。

随着时间的推移，社区提出了一个需求，即允许同时进行发布和测试而不必重新构建应用程序，因为一些用户只希望发布与已经测试过的相同二进制文件的应用程序，这样他们的构建脚本看起来就像：

1. dotnet build the.sln -c Release
2. dotnet test -c Release --no-build
3. dotnet publish the\app.csproj --no-build -c Release

- Martin Ullrich

---

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