build - 为什么要在 dotnet 发布之前打扰 dotnet 构建？

Question

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

所以...

为什么要打扰 dotnet build做之前dotnet publish ?
build自动执行 restore .凉爽的。

好像publish做 build (除非你告诉它不要)。所以...如果您要在之后立即发布，为什么还要费心进行构建？为什么不直接发布，一切都在一步中发生？

为了进一步清楚...

我在一个基本场景中询问，例如:

dotnet build -c Release MyProj

dotnet publish -c Release -o /somedir MyProj

与只是

dotnet publish -c Release -o /somedir MyProj

他们似乎在做同样的事情。

Answer 1

你说得对dotnet publish自动完成所有操作 dotnet build已经做了。在大多数情况下 - 正如你在问题中提到的场景 - 这意味着额外的 dotnet build没有必要。

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

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

dotnet build the.sln -c Release

dotnet test -c Release --no-build

dotnet publish the\app.csproj --no-build -c Release