如何“dotnet pack”一个已经编译的项目答案

【问题标题】：How to "dotnet pack" an already compiled project如何“dotnet pack”一个已经编译的项目
【发布时间】：2018-10-18 07:58:40
【问题描述】：

我正在尝试为执行以下操作的 dotnet core 2.0 项目设计构建脚本

清理输出目录
使用 -o bin\Publish 构建解决方案
使用 dotnet vstest 运行单元测试
使用 dotnet pack 创建 Nuget 包

因为我知道源代码已在步骤 1-3 中构建和测试，所以我不想为 nuget 包重新构建代码，所以我指定 --no-build 和 --no-restore

我遇到的困难是在创建包时，因为我没有构建并且输出目录设置为 bin\Publish - pack 命令正在查找 bin\Debug 目录中的项目。

有没有办法可以将 dotnet pack 命令设置为知道在哪里查找已编译的对象？

这是我的构建脚本的示例

dotnet clean ..\MySolution.sln -o bin/Publish/
dotnet build ..\MySolution.sln /p:Configuration=Release -o bin/Publish/
dotnet vstest ..\MySolution.UnitTests\bin\Publish\MySolution.UnitTests.dll
dotnet pack --no-build --no-restore ..\MySolution.ConsoleApp\MySolution.csproj -o bin\Publish\Nuget\

....

error : The file 'D:\MySolution.ConsoleApp\bin\Debug\netcoreapp2.0\MySolution.ConsoleApp.runtimeconfig.json' to be packed was not found on disk

根据Microsoft Docs on dotnet pack

"默认情况下，dotnet pack首先构建项目。如果你想避免这种行为，传递 --no-build 选项。这通常很有用在您知道代码的持续集成 (CI) 构建场景中是以前建造的。”

所以我希望这是可能的，但我遗漏了一些明显的东西。任何帮助将不胜感激。

【问题讨论】：

标签： .net msbuild .net-core nuget dotnet-cli

【解决方案1】：

原因是dotnet pack --no-build 选项会尝试使用之前构建的输出，但由于您构建到非标准输出路径而无法找到它，并且打包逻辑需要将生成的一些资产定位到构建输出。

-o 选项在内部与 pack 和 build 命令不同，但您可以将 pack 命令更改为：

dotnet pack --no-build --no-restore ..\MySolution.ConsoleApp\MySolution.csproj -o bin\Publish\Nuget\ /p:OutputPath=bin\Publish\

这将使用bin\Publish目录中内置的输出，并将其放入bin\Publish\Nuget\中的Nuget输出目录中

【讨论】：

我就在那儿 - 正如您评论的那样，我只想覆盖 MSBuild 内部参数 - 谢谢您的回答！
--no-build 也将隐式设置 --no-restore （根据文档）
是的，这在 2.1/2.2 中已“修复”，请注意，这个问题最初是关于 2.0 的，但尚未这样做 - github.com/dotnet/cli/pull/8100（这就是为什么我故意在答案中列出两者)
你好。我尝试了这个解决方案，它工作到了一个特定的点，这意味着 Nuget 包的内容都被打乱了，并不是所有的依赖都包括在内。有谁知道为什么？或者我应该怎么做才能包含 \Publish 文件夹的确切内容和结构？
带有dotnet pack 的nuget 包仅包含自己的构建输出，而不包含任何依赖项（这些作为NuGet 依赖项包含在内，因此您会为每个csproj 获得一个.nupkg）。如果你构建工具，你可以构建工具包而不是tutorial doc