为什么要在 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单个项目文件。发布解决方案可能会导致意外结果（从覆盖不同版本的文件到在不应发布到与引用应用程序相同的输出目录的配置中发布库项目等）

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

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