在TeamCity的Core 2.0项目CI/CD中读取.csproj的VersionPrefix属性

Got it, let's break down how to set this up exactly as you need it—pulling VersionPrefix directly from your .csproj, auto-appending that rc suffix with the build counter for develop builds, and keeping your manual version planning workflow intact.

1. Configure VersionPrefix in Your .csproj #

First, make sure your .csproj file explicitly defines the VersionPrefix element. This is what you'll manually update during your planning phase when deciding on Major/Minor/Patch version bumps:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <!-- Manually update this during version planning -->
    <VersionPrefix>1.2.0</VersionPrefix>
    <!-- Leave VersionSuffix empty by default; TeamCity will override it for develop builds -->
    <VersionSuffix></VersionSuffix>
    <TargetFramework>netcoreapp2.0</TargetFramework>
  </PropertyGroup>
</Project>

When you need to bump versions (e.g., from 1.2.0 to 1.3.0 for a minor update, or 2.0.0 for a major release), just edit this VersionPrefix value and commit the change to your develop branch (or directly to master if it's a final release).

2. Set Up TeamCity Build Triggers & Branch-Specific Versioning #

Next, configure TeamCity to handle branch-specific behavior:

• Branch Triggers: Set up a trigger that runs builds whenever code is pushed to the develop branch, and another for master (for formal release builds).
• Branch-Specific Build Steps: Use TeamCity's built-in branch parameter (%teamcity.build.branch%) to conditionally apply the VersionSuffix only for develop builds.

For your dotnet pack or dotnet build step, use commands tailored to each branch:

For Develop Branch Builds #

When the build runs on develop, append the rc suffix with the build counter:

dotnet pack -c Release --version-suffix "rc%build.counter%"

TeamCity will replace %build.counter% with its sequential build number, resulting in a version like 1.2.0-rc42.

For Master Branch Builds #

For master (formal releases), skip the suffix entirely to use the pure VersionPrefix:

dotnet pack -c Release

This will produce a version like 1.2.0 (matching your manually set VersionPrefix).

To make this conditional in TeamCity, use build step conditions:

• Create two separate pack/build steps: one with the suffix command, set to run only when %teamcity.build.branch% equals refs/heads/develop.
• The other step (without the suffix) runs only when the branch is refs/heads/master.

3. Integrate Your Manual Version Planning Workflow #

Your existing planning phase fits perfectly here:

• When your team decides on a version update type (Major/Minor/Patch), edit the VersionPrefix in the .csproj file.
• Commit this change to develop (or merge it into develop from a feature branch).
• The next TeamCity build on develop will pick up the new VersionPrefix and append the rc suffix with the latest build counter.
• When you're ready to release, merge develop into master—the master build will use the final VersionPrefix without any suffix.

4. Verify the Setup #

To confirm everything works as expected:

• Push a change to develop and check the build output—you should see the version formatted as [VersionPrefix]-rc[build_counter].
• Merge to master and run a build—verify the version is exactly the VersionPrefix you set.
• You can also add a quick verification step in TeamCity to print the version, using a command like:

  dotnet msbuild /t:GetVersion /p:VersionSuffix="rc%build.counter%"
  

  This will output the full version number TeamCity will use, letting you double-check before packing.

内容的提问来源于stack exchange，提问作者Aaron Vanmeter