要在 TeamCity 中实现 .NET 项目的持续集成，核心是配置项目构建流程，使其在代码变更时自动触发编译、测试和打包。整个过程不需要手动干预，能快速反馈构建结果，提升开发效率。
配置 VCS 根与项目连接
TeamCity 需要知道你的代码存放在哪里。将你的 .NET 项目（如使用 Git）添加到版本控制系统（VCS）中，然后在 TeamCity 中创建项目并关联仓库。
登录 TeamCity，在主页点击“Create project” 选择从现有仓库导入，比如 GitHub、GitLab 或本地 Git 服务器 输入仓库 URL 和访问凭据（推荐使用 Personal Access Token） TeamCity 会扫描仓库中的构建脚本（如 .sln 或 .csproj 文件），自动推荐构建步骤设置构建步骤
.NET 项目通常使用 MSBuild 或 dotnet CLI 构建。根据项目类型选择合适的构建工具。
进入项目设置，点击“Build Steps” → “Add build step” 对于 .NET Framework 项目，选择“MSBuild”作为构建 runner，指定解决方案文件路径（如 src/MyApp.sln） 对于 .NET Core/.NET 5+ 项目，选择“dotnet” runner，命令选“build”，目标文件填 **/*.csproj 或具体 sln 文件 可添加额外参数，如 --configuration Release运行单元测试并生成报告
持续集成的关键是自动运行测试，确保代码质量。
在构建步骤中添加新的 step，使用“dotnet” runner，命令设为“test” 确保测试项目包含 xUnit、NUnit 或 MSTest 框架，并引用 Microsoft.NET.Test.Sdk 启用测试结果统计：在“Report paths”中添加 **/test-results.xml 或使用 TeamCity 内置的 XML 报告支持 建议开启“Fail build on metric change”来防止测试覆盖率下降配置触发器与构建产物
让构建在每次提交后自动启动，并保留输出文件。
进入“Triggers” → 添加“VCS Trigger”，设置为“Trigger on each check-in” 在“Build Features”中启用“Build Failure Conditions”，例如测试失败或超时则标记构建失败 在“Artifacts Path”中指定输出目录，如: out => **/publish/** 可在构建脚本中使用 dotnet publish -c Release -o ./out 将应用打包基本上就这些。只要仓库连接正确，构建步骤清晰，TeamCity 就能自动监控代码变化、执行构建和测试。一旦配置完成，团队每次提交都能获得即时反馈，真正实现持续集成的目标。不复杂但容易忽略的是权限设置和代理环境（Agent）是否安装了对应版本的 .NET SDK。确保构建机上运行 dotnet --list-sdks 能看到所需版本。基本上就这些。
