【问题标题】:dotnet publish output folder?dotnet 发布输出文件夹?
【发布时间】:2019-06-19 09:20:24
【问题描述】:

dotnet publish 命令发布到项目bin/netcoreapp2.2/Debug/publish 文件夹中。其中netcoreapp2.2 可能随 dotnet 版本而变化,Debug-c 参数指定的任何配置而变化。

对于 CI/CD 而言,这显然是不可取的。或者,可以通过-o 传递显式输出路径,但同样,在 CI/CI 环境中,此路径应该在项目文件夹结构内,例如类似:

dotnet publish -o publish

但是,因为发布命令会收集所有文件,所以它会选择以前的发布尝试并递归地存储它们。这可以通过显式清理发布文件夹和/或将 a 添加到项目的 csproj 来缓解,但现在构建脚本和 csproj 之间存在依赖关系:如果构建脚本中的发布路径因任何原因而更改如果没有相应的 csproj 更新,事情就会中断。

因此,最不脆弱的选项似乎是使用默认输出路径,因为那会自动从 globbing 中排除,但是如何删除版本和配置敏感性?有没有一种特别安全的方法可以让 dotnet 告诉我的 CI/CD 环境其构建/发布的输出路径是什么?

【问题讨论】:

    标签: .net-core continuous-integration gitlab-ci


    【解决方案1】:

    IMP:我没有足够的声望来添加评论

    参考:dotnet publish

    您可以使用带有 -o 选项的相对路径,您最终可能会避免使用运行时、平台标识的文件夹名称。

    您为什么不考虑使用带有发布配置文件的构建命令,您可以在其中指定显式路径。但通常相对路径不太容易出错。

    希望对你有帮助!

    【讨论】:

    • 绝对路径不可用,因为构建运行器服务器有多个运行器,因此两个构建可能会尝试同时使用相同的“c:\publish”文件夹。相对路径是不可取的,因为它们会递归地被全局化,虽然这可以修复,但我对不可见的依赖关系不满意,因为这违反了“最少意外”的原则。
    • 您尝试发布配置文件了吗:docs.microsoft.com/en-us/aspnet/core/host-and-deploy/…
    • 选项 1:您是否尝试发布配置文件:Publish Profiles 这可能会解决默认文件夹名称和相对路径的问题,您可以在其中指定绝对路径。但是一天结束时,我们必须通过相对或绝对来指定路径。选项 2:您可以使用 CI/CD 管道变量或环境变量存储绝对路径,并在命令中使用它们 - 似乎代码/项目不知道发布路径
    猜你喜欢
    • 2016-08-12
    • 2021-10-11
    • 2017-03-02
    • 2019-03-16
    • 1970-01-01
    • 2018-09-29
    • 1970-01-01
    • 1970-01-01
    • 2021-11-23
    相关资源
    最近更新 更多