很多團隊或開發者都會使用 C#、VB 等語言開發 .Net 應用。.NET 版本號的管理與對應代碼的質量管理是一個比較充滿挑戰的話題。本文將介紹使用極狐GitLab CI 來實現 .NET 應用的版本號自動生成以及代碼的增量掃描，從而提高 .NET 應用的研發效率。

.NET nuget 自動生成測試包（prerelease）版本號

NET 包（nuget）的版本號位於項目配置文件中（比如 Foo.csproj），比如這個包是 1.1.0 版本：

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <Version>1.1.0</Version>
  </PropertyGroup>
</Project>

當開發新版時（比如 1.2.0），可能需要發佈測試包，供聯調和測試，當測試通過時，才會發佈正式包。

可以使用這種 Git 工作流（也有其他工作流，大同小異）：

• 開發分支（如 feature-123）或合併請求（MR/PR）時：發佈測試包；
• 主幹分支或 Tag 時：發佈正式包。

.NET 版本號規範

.NET 測試包的官方術語是 prerelease（預發行版），在 Visual Studio 包管理界面有一個開關：

版本號遵循語義化版本規範，常用如下命名：

• alpha：Alpha 版本，通常用於在製品和試驗品
• beta：Beta 版本，通常指可用於下一計劃版本的功能完整的版本，但可能包含已知 bug。
• rc：候選發佈，通常可能為最終（穩定）版本，除非出現重大 bug。

如果項目測試流程不是很複雜，採用其中一個就夠了，本文采用 beta。

所以版本號的變化歷程可能是這樣的：1.1.0 → 1.2.0-beta.1 → 1.2.0-beta.2 → 1.2.0-beta.3 → 1.2.0

如果手動修改，多次改代碼很容易忘記改版本號。

有沒有辦法自動修改版本號？可以！那就是持續集成。

持續集成自動打包

提交代碼，觸發程序自動打包，這是持續集成的典型用途。使用 GitLab 持續集成配置 .NET 自動打包非常簡單：

vi MyDotnetLibrary/.gitlab-ci.yml

.gitlab-ci.yml 的內容如下：

image: mcr.microsoft.com/dotnet/sdk:6.0

default:
  before_script:
    - dotnet nuget add source "$CI_SERVER_URL/api/v4/projects/$CI_PROJECT_ID/packages/nuget/index.json" -n GitLab -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD --store-password-in-clear-text

build_release:
  stage: build
  only:
    - main
  script:
    - rm -rf *.Tests
    - dotnet pack **/*.csproj -c Release
    - dotnet nuget push **/bin/Release/*.nupkg -s GitLab

可以看到上面代碼判斷了 only: - main，也就是主幹分支時才打包。

持續集成自動修改版本號

開發新版本時，只需要修改一次版本號（比如 1.2.0）：

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <Version>1.2.0</Version>
  </PropertyGroup>
</Project>

然後，讓持續集成自動判斷：

• 合併請求：在版本號後面添加測試版本號，變成 1.2.0-beta.123；
• 主幹分支：不添加，保持 1.2.0。

GitLab 流水線內置了很多變量，有幾個適合做測試版本號：

• CI_PIPELINE_IID：項目內的流水線 ID，從 1 開始自增，每次提交觸發流水線都會自增；
• CI_MERGE_REQUEST_IID：項目內的合併請求 ID，從 1 開始自增，每次新建合併自增，但多次提交不會變。

可以看出 CI_PIPELINE_IID 適合做測試包的構建號。

拼接出想要的格式，使用 sed 命令替換：

export CI_PIPELINE_IID=123
sed "s|</Version>|-beta.$CI_PIPELINE_IID</Version>|g" **/*.csproj

本地跑通命令，再把它複製到 .gitlab-ci.yml 中：

image: mcr.microsoft.com/dotnet/sdk:6.0

default:
  before_script:
    - dotnet nuget add source "$CI_SERVER_URL/api/v4/projects/$CI_PROJECT_ID/packages/nuget/index.json" -n GitLab -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD --store-password-in-clear-text

build_prerelease:
  stage: build
  only:
    - merge_requests
  script:
    - rm -rf *.Tests
    - sed -i "s|</Version>|-beta.$CI_PIPELINE_IID</Version>|g" **/*.csproj
    - dotnet pack **/*.csproj -p:IncludeSymbols=true -p:SymbolPackageFormat=snupkg -c Debug
    - dotnet nuget push **/bin/Debug/*.nupkg -s GitLab

build_release:
  stage: build
  only:
    - main
  script:
    - rm -rf *.Tests
    - dotnet pack **/*.csproj -p:IncludeSymbols=true -p:SymbolPackageFormat=snupkg -c Release
    - dotnet nuget push **/bin/Release/*.nupkg -s GitLab

運行效果：

.NET 行級增量代碼規範——拯救老項目

從 .NET 5 開始，SDK 內置了代碼分析器，可以檢查 C# 和 Visual Basic 的代碼質量和樣式問題，無需安裝第三方工具，非常方便。

本地全量代碼規範

修改項目配置文件（如 Foo.csproj、Bar.vbproj），加入 AnalysisMode 和 ErrorLog 屬性：

<Project>
  <PropertyGroup>
    <AnalysisMode>All</AnalysisMode>
    <ErrorLog>compiler-diagnostics.sarif</ErrorLog>
  </PropertyGroup>
</Project>

AnalysisMode 允許這些值，按照從鬆到嚴排序為：

• None；
• Default；
• Minimum；
• Recommended；
• All。

配置完成，即可在編譯時檢查代碼規範，可在 VS 界面點擊或使用命令：

dotnet build

如果本地電腦語言為中文，.NET 會輸出部分中文（3 條），但大部分信息還是英文的（96 條）。

可以看出全量掃描發現很多問題，怎麼辦？

• 一個人清理乾淨，其他人暫停提交。顯然不合適；
• 所有人暫停工作，一起清理。也不合適，老代碼改了可能出 bug；
• 增量代碼規範，逐漸修復。是個好辦法，在本地很難做到，可以藉助 GitLab 服務端實現。

行級增量代碼規範

配置 GitLab 持續集成 .gitlab-ci.yml：

image: mcr.microsoft.com/dotnet/sdk:6.0

build:
  stage: build
  allow_failure: true
  script:
    - dotnet build
  after_script:
    - export PATH="/root/.dotnet/tools:$PATH"
    # 此工具要求 .NET 6.0+，如果項目是 .NET 5.0，也使用 6.0 SDK 構建即可
    - dotnet tool install --global CodeQualityToGitlab
    - cq sarif compiler-diagnostics.sarif gl-code-quality-report.json $(pwd)/
  artifacts:
    reports:
      codequality: gl-code-quality-report.json

第一次 MR（提交 .gitlab-ci.yml） 會發現「全量的很多問題」或「代碼質量沒有變化」，沒關係，先合併進去。

第二次 MR（修改老代碼）會在 MR 頁面提示修改的代碼行是否產生了新問題，是否修復了老問題。

這就是 GitLab 的行級增量代碼規範功能，它有幾個特點：

• 配置簡單——配置全量掃描命令，自動變成增量；
• 除了報錯模式，還支持警告模式（allow_failure）——由評審人員決定「代碼不規範時能否合併」，一般不允許合併，如果線上緊急故障可以合併；
• 提升開發效率——把代碼質量問題直接顯示在合併請求頁面中，而無需到 CI 日誌中翻找；
• 開放——公開代碼質量報告 JSON 格式，各種語言的掃描工具都可以對接（很多工具已經有熱心開發者對接，比如 Java Checkstyle、pylint、eslint）。

希望本文能幫助更多的開發者拯救老項目，落地代碼規範。