gitlab CI运行器c#依赖项在MSbuild中全部失败
本文关键字：MSbuild 全部 失败 依赖 CI 运行 gitlab | 更新日期: 2023-09-27 18:18:30
我有一个运行器(配置了这个脚本的轻微修改)，它应该构建和单元测试一个解决方案，其中包含一个ASP。. NET CORE项目，JS less web前端，以及单元测试项目。
然而，当MSbuild试图构建项目时，每个项目中的每个依赖项都失败了(超过150条错误消息)，错误为NU1001。
这是除了一些非常奇怪的行为-它试图使用visual studio 2012来构建，即使VS 2012从未安装在这台机器上。它还拒绝接受原始脚本中的%project_name参数。我不得不硬编码一个位置和版本，甚至让它进入构建阶段。
从原始脚本的nuget被删除，因为它是破碎的。后来我发现文档说明nuget现在自动刷新包的构建，所以它不需要重新添加。
我不认为这是一个gitlab-ci问题。将调试工作集中在与正在使用的运行器相关联的服务器(或容器内)上执行MSBuild命令。
我建议使用before_script调用一个脚本，该脚本验证管道所需的依赖项。例如，您的预构建脚本可以验证MSBuild, NuGet和Git是否在您的运行器/VM/容器的路径上(这允许您使用Puppet或Powershell DSC来控制这些先决条件，而不是在管道中管理它们)。
nuget restore应作为restore阶段的一部分而不是在before_script中调用。恢复后的包可以作为工件在各个阶段之间传递。
您在build作业中对MSBuild的调用使用了双引号。下面是我如何在我目前正在使用的管道中调用MSBuild:
build_dev:
stage: build
script:
- MSBuild $env:TARGETS /t:Build /p:Configuration=Debug
artifacts:
paths:
- ./*/bin
<<: *default_expiration
<<: *default_tags
在这个场景中，我的before_script已经验证了MSBuild在路径上，所以我可以自由地使用它。它可能指的是MSBuild 12.0或14.0，具体取决于运行程序。$env:TARGETS来自gitlab-ci变量;它指向一个MSBuild文件，build.targets。
我相信你使用的是基本的shell执行器;当您在运行器配置中指定shell = powershell时，有些事情会变得更容易，Powershell语法更适合拼凑管道。
最后，MSBuild是否自动恢复NuGet依赖关系实际上取决于您的.csproj文件的编写方式。我认为最好将nuget restore作为单独的步骤。例如，当您需要恢复MSBuild本身使用的Nuget包时，单独的步骤会派上用场。
验证简单运行MSBuild对您的解决方案文件自动恢复NuGet包通过运行MSBuild自己在命令行。我不认为gitlab-ci会影响这个命令的成功。