为什么要在 dotnet 发布之前打扰 dotnet 构建? [英] Why bother with dotnet build before dotnet publish?

问题描述

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

Welp. This seems like the type of question where I'll facepalm seeing the answer.

所以...

在执行 dotnet publish 之前，为什么还要麻烦 dotnet build?

Why bother with dotnet build before doing a dotnet publish?

build 自动执行 restore.凉爽的.

build automatically does a restore. Cool.

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

It seems publish does a build (unless you tell it not to). So... Why bother doing the build if you're going to publish right after? Why not just publish and everything happens in one step?

为了进一步清楚...

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

I am asking in a basic scenario like:

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

对比只是

• dotnet publish -c Release -o/somedir MyProj

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

They seem to do the same thing.

推荐答案

您说得对，dotnet publish 会自动完成 dotnet build 已经完成的所有工作.在大多数情况下 - 正如问题中提到的场景 - 这意味着不需要额外的 dotnet build.

You are right that dotnet publish automatically does everything dotnet build already does. In most cases - as in your scenario mentioned in the question - that means an additional dotnet build is not necessary.

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

Do note that you can dotnet build a solution, but should only dotnet publish individual project files. Publishing solutions likely leads to unexpected results (from overriding files of different versions to publishing library projects in configurations that should not be published to the same output directory as referencing applications etc.)

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

Over time there was a community ask to allow both publishing and testing without potentially rebuilding the app, because some users felt more comfortable only ever publishing an application with the same binaries that have been tested so their build scripts can look like:

1. dotnet build .sln -c 发布
2. dotnet test -c Release --no-build
3. dotnet 发布app.csproj --no-build -c 发布

这篇关于为什么要在 dotnet 发布之前打扰 dotnet 构建?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！