Need help reading the new project file format

[devdelimited]

I have added the GitVersion step to my DevOps pipeline through the GUI. However, the log does not seem to reflect that it is reading the new .NET Core-based project file format (no AssemblyInfo.cs file at all and no YAML).

For testing, I have set the Version to 0.1.1 in the project file, committed and pushed. However, GitVersion appears to revert to the default 0.1.0-alphaXXXX. The logs show that it has loaded the .git folder to parse the branches, etc. but it doesn't seem to even try to look for or read any project files.

What am I missing? Do I need to specify the project file location with a command line parameter? I have tried both /targetprojectfiles and /updateprojectfiles, but it really does not like those at all.

[asbjornu]

The project file isn't used as a version source by GitVersion, afaik.

[devdelimited]

To clarify, I would have expected the version on the release/1.0.0 to be, simply, 1.0.0 (plus some build number).

The issue with main could simply be avoided by not running a build at all - since a build was already done on the release. However, it would be nice if it would use the merged-in version 1.0.0 (plus the next build number).

As far as I can tell, postfixes should only be added on branches other than main, release, and hotfix, but that does not appear to be the behavior.

[devdelimited]

For others, marking the original response as the answer, because asbjornu is 100% correct. It is a change in thinking, but correct.

My issues of wrestling with the resulting determined version values persists though.

[asbjornu]

Oh and by the way, it's preference for using manually tagged commits is a non-starter.

If typing git tag <major.minor.patch> every now and then to actually codify in your repository which commit represents an actual release in your system, I don't think GitVersion is the tool for you. It's possible to use conventional commits and commit messages to increment the version, but I don't recommend it.

To clarify, I would have expected the version on the release/1.0.0 to be, simply, 1.0.0 (plus some build number).

Only tagged commits are considered stable by GitVersion. A release branch is not stable before it is merged into main and that merge-commit is tagged. A release branch can live for a long while, receiving updates to stabilize the release. If you perform builds and produce published artifacts from that release branch, those artifacts aren't considered stable. At least not by anyone else using Git Flow or GitVersion.

As far as I can tell, postfixes should only be added on branches other than main, release, and hotfix, but that does not appear to be the behavior.

I agree that the -main suffix is strange. I would love to see a reproduction of that behaviour in a public repository or a RepositoryFixture test in a pull request.

[devdelimited]

Regarding the issue with adding -main to the end, there was no magic involved. I simply created a solution with a class library project and initialized git-flow on it. I didn't tag anything at all. I created a release/1.0.0 branch and started playing with Azure Pipelines & GitVersion. The only thing that may have bitten me was that I set my nuget pack task to explicitly use the GitVersion.NuGetVersion variable. That's pretty much it.

Unfortunately, I've had to move on from this. We are now cheating. We created a PowerShell script to make some educated guesses at what the version should be and stuffed that into a variable. Then, we use that variable to call git tag and tag the local build host copy of the repo right before running GitVersion. So, ultimately, we are only using GitVersion now to locally modify any AssemblyInfo or project files right before the build task. The tag never gets persisted back into the DevOps repo, so our only ultimate version source or system of record are the actual release branches, thereby avoiding any potential conflicts or confusion between tags and branches.

I was really hoping to avoid using trashy PowerShell scripts in our pipelines, but here we are.

In any case, despite my frustrated tone, I appreciate the help you provided. I understand that GitVersion was built with a different set of priorities in mind.

[asbjornu]

our only ultimate version source or system of record are the actual release branches

As branches usually aren't persisted after they are merged, I would say this is not a wise strategy.

I was really hoping to avoid using trashy PowerShell scripts in our pipelines, but here we are.

If you prefer having "trashy PowerShell scripts" over doing git tag manually every now and then, that's up to you.

In any case, despite my frustrated tone, I appreciate the help you provided. I understand that GitVersion was built with a different set of priorities in mind.

No problem, I'm glad you've found a solution that works for you.