Jenkins如何构建C#项目-C#.Net教程-PHP中文网

在jenkins中构建c#项目，最稳妥的配置方式是明确指定msbuild完整路径，并使用/p:configuration=release /p:platform="any cpu" /t:rebuild参数组合。1. 明确指定msbuild完整路径，如c:\program files (x86)\microsoft visual studio\vs_version\buildtools\msbuild\current\bin\msbuild.exe，避免依赖环境变量；2. 使用release配置确保生成优化后的部署版本；3. 指定"any cpu"平台，适用于大多数项目，确保兼容性；4. 使用/t:rebuild目标确保每次构建前清理，避免残留文件影响构建结果；5. 若路径含空格，使用双引号包裹路径；6. 可通过/p:solutiondir或/p:projectdir指定具体项目路径，或直接构建.csproj文件。此外，构建日志是排查失败的第一步，msbuild会输出详细错误信息便于定位问题。

Jenkins如何构建C#项目

Jenkins构建C#项目，核心在于利用其强大的自动化能力，结合微软的MSBuild工具链，实现代码拉取、编译、测试乃至部署的全流程自动化。这不仅能大幅提升开发效率，还能确保构建的一致性和可靠性，避免“在我机器上能跑”的尴尬。

解决方案

环境准备与核心配置

在Jenkins服务器上，你需要确保安装了合适的.NET SDK或Visual Studio Build Tools。这是构建C#项目的基础，因为MSBuild.exe是编译的核心工具。对于较新的.NET项目（.NET Core/.NET 5+），安装对应的.NET SDK就足够了，它包含了dotnet命令行工具，能够处理构建和包还原。

接着，在Jenkins里安装MSBuild Plugin。这个插件提供了一个方便的界面来调用MSBuild，虽然你也可以直接在“执行Shell”或“执行Windows批处理命令”中调用，但插件能更好地集成MSBuild的输出和状态。

任务创建与源码管理

创建一个新的Jenkins任务，通常“自由风格项目”是起点，它提供了最大的灵活性。如果你想更进一步，Jenkins Pipeline（流水线）是更推荐的方式，它允许你用代码定义整个构建流程，可维护性和可追溯性都更好。

在源码管理部分，配置你的版本控制系统（Git、SVN等），指向你的C#项目仓库。确保Jenkins有权限拉取代码。

构建步骤详解

NuGet包还原： 绝大多数C#项目都依赖NuGet包。在进行编译之前，必须先还原这些包。
- 对于传统.NET Framework项目，通常是执行nuget restore YourSolution.sln。你需要确保Jenkins服务器上安装了NuGet CLI。
- 对于.NET Core/.NET 5+项目，直接使用dotnet restore YourSolution.sln。dotnet命令通常随SDK一起安装。
- 这一步至关重要，如果包没有正确还原，后续的编译会失败。
项目编译： 这是核心步骤。
- 使用MSBuild Plugin： 在构建步骤中选择“Build a Visual Studio project or solution using MSBuild”。
  - MSBuild Version： 选择你服务器上安装的MSBuild版本。
  - MSBuild Build File： 填写你的解决方案文件路径，例如YourProject/YourSolution.sln。
  - Command Line Arguments： 这里是关键，通常会是/p:Configuration=Release /p:Platform="Any CPU" /t:Rebuild。Rebuild会先清理再构建，确保一个干净的构建环境。根据你的项目需要，可以调整Configuration（例如Debug）和Platform。
- 直接命令行： 如果你更喜欢完全控制，或者使用dotnet build，可以在“执行Windows批处理命令”或“执行Shell”中操作。
  - msbuild YourSolution.sln /p:Configuration=Release /p:Platform="Any CPU" /t:Rebuild
  - dotnet build YourSolution.sln -c Release --no-restore (注意，这里假设你前面已经执行了dotnet restore)
单元测试执行（可选但强烈推荐）： 编译完成后，运行单元测试是保障代码质量的重要环节。
- 根据你使用的测试框架（NUnit, xUnit, MSTest），选择对应的命令行工具。
- 例如：
  - NUnit：nunit3-console.exe YourTests.dll --result=TestResults.xml
  - xUnit：dotnet test YourTests.csproj --logger "trx;LogFileName=TestResults.trx"
  - MSTest：vstest.console.exe YourTests.dll /logger:trx
- 将测试结果输出到XML或TRX文件，以便后续Jenkins插件解析并展示。
发布构建产物（可选）： 将编译生成的DLL、EXE、Web部署包等复制到指定的发布目录，或打包成ZIP文件。
- 使用“Copy Artifact”插件，或直接用命令行复制。
- 例如：xcopy /s /e /y YourProject\bin\Release\*.* D:\PublishLocation\
后构建操作（可选）：
- 发布测试结果： 使用“Publish NUnit test result report”、“MSTest plugin”等插件，解析前面生成的测试报告文件，在Jenkins界面上展示测试结果和趋势。
- 邮件通知： 配置构建成功或失败时的邮件通知。
- 归档制品： 将构建生成的二进制文件、部署包等归档起来，方便下载和追溯。

在Jenkins中，C#项目的MSBuild路径和参数怎么配置才最稳妥？

说实话，这地方经常踩坑。最稳妥的方式，我认为是明确指定MSBuild的完整路径，而不是依赖系统环境变量。Jenkins有时环境配置会比较“洁癖”，或者说，它运行的用户账户可能没有你期望的那些环境变量。

MSBuild路径的确定：

对于旧版Visual Studio（如VS2017/2019），MSBuild.exe通常位于C:\Program Files (x86)\Microsoft Visual Studio\<VS_VERSION>\BuildTools\MSBuild\Current\Bin\MSBuild.exe或C:\Program Files (x86)\Microsoft Visual Studio\<VS_VERSION>\<EDITION>\MSBuild\Current\Bin\MSBuild.exe。BuildTools版本更轻量，适合服务器环境。

对于.NET Core/.NET 5+项目，你可能更倾向于使用dotnet build命令。这个命令通常在安装.NET SDK后就可以直接在命令行中使用，因为它会被添加到系统PATH中。如果Jenkins找不到，可以尝试指定dotnet.exe的完整路径，通常在C:\Program Files\dotnet\dotnet.exe。

参数配置：

最常用的参数组合是/p:Configuration=Release /p:Platform="Any CPU" /t:Rebuild。

/p:Configuration=Release：指定构建配置为“Release”。这很重要，因为“Release”配置通常会进行代码优化，并移除调试信息，生成最终部署所需的版本。
/p:Platform="Any CPU"：指定目标平台。对于大多数C#项目，Any CPU是默认且推荐的选项。如果你有特定的x86或x64依赖，需要相应调整。
/t:Rebuild：这个目标（Target）命令MSBuild先执行Clean（清理），再执行Build（构建）。这能确保每次构建都是从一个干净的状态开始，避免了增量构建可能带来的不确定性或残留文件问题。虽然Build也能工作，但Rebuild在CI/CD环境中更可靠。

一些小细节：

如果项目路径或解决方案路径包含空格，记得用双引号括起来。
如果你有多个项目，或者只想构建解决方案中的特定项目，可以通过/p:SolutionDir="C:\Path\To\Solution\"和/p:ProjectDir="C:\Path\To\Project\"等参数来辅助定位，或者直接指定要构建的.csproj文件而不是.sln文件。
遇到构建失败，查看Jenkins的构建日志是第一步。通常MSBuild会输出详细的错误信息，告诉你哪个文件、哪一行出了问题。

如何处理C#项目中的NuGet包依赖问题？

NuGet包依赖，这是个老生常谈的问题了，尤其是当你的项目依赖的包越来越多，或者涉及到私有NuGet源的时候。在Jenkins上处理这个问题，核心思想是在编译之前，确保所有的包都已经被正确还原到项目能够找到的位置。

核心命令：nuget restore 或 dotnet restore

笔目鱼英文论文写作器

写高质量英文论文，就用笔目鱼

查看详情

nuget restore (适用于传统.NET Framework项目): 在Jenkins的构建步骤中，通常会在MSBuild编译之前，添加一个“执行Windows批处理命令”步骤，运行nuget restore YourSolution.sln。前提是你的Jenkins服务器上需要安装NuGet CLI工具。你可以手动下载nuget.exe并放到一个PATH可访问的目录，或者直接在Jenkins任务中指定其完整路径。
dotnet restore (适用于.NET Core/.NET 5+项目): 对于这些新一代的项目，dotnet restore YourSolution.sln是首选。它通常随.NET SDK一起安装，所以只要Jenkins能找到dotnet命令，就可以直接使用。这个命令不仅还原包，还会处理项目间的引用。

处理私有NuGet源：

这是一个常见的痛点。如果你的项目依赖公司内部的私有NuGet源，直接运行nuget restore或dotnet restore可能会因为认证问题而失败。

NuGet.Config配置： 最推荐的做法是在你的解决方案根目录或用户目录下放置一个NuGet.Config文件。这个文件可以定义包源，包括私有源的URL。

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="MyPrivateFeed" value="http://your-private-nuget-server/nuget" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
  <packageSourceCredentials>
    <MyPrivateFeed>
      <add key="Username" value="jenkins_user" />
      <add key="ClearTextPassword" value="your_password" />
    </MyPrivateFeed>
  </packageSourceCredentials>
</configuration>

登录后复制

注意： 直接在NuGet.Config中明文存储密码不安全。更好的做法是使用Jenkins的Credentials插件，配合dotnet nuget add source或nuget sources add命令，在构建脚本中动态添加带凭据的源。

Jenkins Credentials Plugin + NuGet Authenticate Plugin： 这是更安全的做法。你可以将私有NuGet源的用户名和密码存储在Jenkins的Credentials中。然后，使用NuGet Authenticate插件，它可以在构建开始前，根据Jenkins的凭据，生成一个临时的NuGet.Config文件，包含认证信息，供nuget restore或dotnet restore使用。构建结束后，这个临时文件会被清理。

网络问题：

确保Jenkins服务器能够访问NuGet官方源（api.nuget.org）或你的私有源。防火墙、代理设置都可能成为障碍。如果Jenkins运行在内网，而NuGet源在外网，可能需要配置Jenkins的HTTP代理。

Jenkins构建C#项目时，如何集成单元测试并生成报告？

集成单元测试是CI流程中不可或缺的一环，它能及时发现代码回归和潜在问题。在Jenkins中，我们通常会在编译成功后立即执行测试，并解析测试结果，以便在Jenkins界面上直观地看到测试的通过率和失败详情。

选择合适的测试运行器：

这取决于你C#项目使用的单元测试框架：

NUnit： 使用nunit3-console.exe。
- 执行命令： 在构建步骤中添加一个“执行Windows批处理命令”或“执行Shell”步骤，命令类似："C:\path\to\NUnit.ConsoleRunner.3.x.x\tools\nunit3-console.exe" YourTests.dll --result=TestResults.xml;format=NUnitV2。
- YourTests.dll是你的测试项目编译后的DLL文件。
- --result=TestResults.xml 指定将测试结果输出到XML文件，这是Jenkins插件解析的基础。
xUnit.net： 通常通过dotnet test命令来运行。
- 执行命令： dotnet test YourTests.csproj --logger "trx;LogFileName=TestResults.trx"。
- --logger "trx" 指定输出TRX格式的测试报告，这是Visual Studio和Jenkins都能理解的格式。
MSTest： 使用vstest.console.exe。
- 执行命令： "C:\Program Files (x86)\Microsoft Visual Studio\<VS_VERSION>\BuildTools\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" YourTests.dll /logger:trx。
- 同样，/logger:trx是为了生成TRX报告。

集成测试报告到Jenkins：

生成了XML或TRX格式的测试报告后，你需要让Jenkins能够读取并展示它们。这通常通过Jenkins插件实现。

Publish NUnit test result report： 如果你使用NUnit，安装这个插件。在构建后的操作中选择“Publish NUnit test result report”，然后指定你的TestResults.xml文件路径（支持通配符，例如**/TestResults.xml）。它会在Jenkins的任务页面上生成一个“Test Result”链接，展示测试概览、通过率、失败详情等。
MSTest plugin / JUnit plugin： 如果你生成的是TRX文件（xUnit或MSTest），可以使用“MSTest plugin”或更通用的“JUnit plugin”（因为TRX文件可以转换为JUnit XML格式）。
- 对于MSTest plugin，直接指定TRX文件路径。
- 对于JUnit plugin，你需要一个额外的步骤，将TRX文件转换为JUnit XML格式。有一些工具或脚本可以完成这个转换。例如，可以使用trx2junit工具。

代码覆盖率（Code Coverage）：

除了单元测试结果，代码覆盖率也是衡量测试质量的重要指标。

OpenCover： 这是一个流行的.NET代码覆盖率工具。
- 集成步骤： 在执行测试命令时，用OpenCover包裹你的测试运行器。例如： "C:\path\to\OpenCover.Console.exe" -register:user -target:"C:\path\to\NUnit.ConsoleRunner.3.x.x\tools\nunit3-console.exe" -targetargs:"YourTests.dll --result=TestResults.xml" -output:coverage.xml
- -output:coverage.xml 会生成一个XML格式的覆盖率报告。
Coverlet： 对于.NET Core/.NET 5+项目，Coverlet是一个更好的选择，它与dotnet test集成紧密。
- 集成步骤： dotnet test YourTests.csproj /p:CollectCoverage=true /p:CoverletOutputFormat=opencover /p:CoverletOutput=coverage.xml
Jenkins插件： 生成覆盖率报告后，使用“Cobertura Plugin”或“JaCoCo Plugin”（虽然JaCoCo主要用于Java，但如果报告格式兼容，也可以尝试）来解析并展示覆盖率报告。在构建后的操作中配置插件，指向生成的coverage.xml文件。