-2

My current situation:

I would like to apply this to a solution containing multiple projects (one executable and different libraries) in C#. Additionally, I have a project that packs the executable, libraries and the .NET (currently v6.0) framework into an MSI installation package, which name should contain the product version.

Other experiences:

I have different GitHub repositories (C++ libraries) on which the version number is automatically assigned on every pull request according to the commit messages. The logic is as follows:

  • Commit messages follow the conventional commits specifications
  • A CI work action is setup to bump the (semver) version (stored into a JSON file on the root of the repository) according to the commit message.
  • A tag is assigned with this version
  • A .zip and .gzip packages are made available

Every repository is built with cmake.

What I want to solve:

I imagine a similar workflow for my C# application whenever there is a new PR on master/main:

  • Commit messages follow the conventional commits specifications
  • A CI work action to bump (product) version and update it into the solution.
  • A tag with this version to be assigned.
  • The installation package creation is launched (no idea how yet)

Questions:

  • Does this workflow make sense on these kind of solutions?
  • Any experiences with it?
  • What is the role the assembly version plays in all this?
  • Where to maintain these numbers, is it in the AssemblyInfo.cs?
  • Is this file generated automatically nowadays or should I create it by myself?
5
  • A common approach is to obtain serial numbers from GitHub Issues, and start each feature branch name with an issue number. Then the PR is all about closing out a specific issue. I have seen this work well, both with repos that use Conventional Commits and with repos that don't. One of the things PR edits are responsible for is bumping the SemVer as appropriate. But I see you are headed down quite a different path, more power to you.
    – J_H
    Feb 6 at 18:28
  • you can compile with dotnet build -p:Version=1.2.3.4 which will overwrite the version in the project file
    – Ewan
    Feb 6 at 18:32
  • @Ewan I didn't know that. I guess that works also with "dotnet publish" which is what I use within my Wix Toolset authoring for creating the installation package.
    – jav
    Feb 6 at 19:15
  • @J_H mine is a private repository and we do not use the GitHub Issues. That is why using the commit messages for bumping the version and creating a new installation package suits me better.
    – jav
    Feb 6 at 19:17
  • Assembly version should be roughly an API version, it wouldn't necessarily bump when a change is made, only if clients should need to rebuild (and update references). Assembly file version should bump on every change. If you have an SDK-style project, the assembly info can be in the project file and managed by the MSBuild command line. If you have AssemblyInfo.cs, then you can use the WriteCodeFragment task in MSBuild to write changing assembly info (like version numbers) into an autogenerated fragment to include in the project.
    – Craig
    Feb 7 at 15:15

1 Answer 1

1

Brief Answers:

  • Does this workflow make sense on these kind of solutions?

CI pipeline keeps track of version, auto bumps every build and manually can be incremented for major/minor ? Yes

  • Any experiences with it?

Sure, I think this is standard these days

  • What is the role the assembly version plays in all this?

with dotnet core you can just use <Version> in the project file. There are some other version elements you can use as well if you want more advanced stuff

  • Where to maintain these numbers, is it in the AssemblyInfo.cs?

Dot net core will still work with assemblyinfo.cs but its not part of the standard template. Just use the project file.

You will need to keep track of the latest build version, the usual place to do this is in the build pipeline. Most code repository/build systems offer a way to store and update build numbers.

  • Is this file generated automatically nowadays or should I create it by myself?

The project file is automatically generated, You will need to add the version element and use the dotnet build -p:Version=<insert version from build pipeline> command to overwrite it with your current version in the CI pipeline.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.