skarpdev / dotnet-version-cli Goto Github PK

So that the output becomes

Bumped abc.csproj from x.y.z to x.y.z

The yearly expiration point has been reached so it's time for a new key

When using the --dry-run option the tool still changes the csproj, writes the commit and creates the tag.

From reading the README file on this project, I'd expected the tool to only output the version number calculated when using the --dry-run option.

Example commands to reproduce the unexpected behavior:

dotnet version --prefix preview preminor --dry-run

dotnet version preminor --dry-run

If you need more information let me know.

PS: the .NET project I tried this tool on was this.

Thanks for the tool.

With usage in M1 Macs the cli complains over architecture:

Below is a sample error found on my machine

╰─ dotnet version prerelease
Failed to load /usr/local/share/dotnet/host/fxr/7.0.0/libhostfxr.dylib, error: dlopen(/usr/local/share/dotnet/host/fxr/7.0.0/libhostfxr.dylib, 0x0001): tried: '/usr/local/share/dotnet/host/fxr/7.0.0/libhostfxr.dylib' (mach-o file, but is an incompatible architecture (have '**arm64**', need '**x86_64**')), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/share/dotnet/host/fxr/7.0.0/libhostfxr.dylib' (no such file), '/usr/local/share/dotnet/host/fxr/7.0.0/libhostfxr.dylib' (mach-o file, but is an incompatible architecture (have '**arm64**', need '**x86_64**'))
The library libhostfxr.dylib was found, but loading it from /usr/local/share/dotnet/host/fxr/7.0.0/libhostfxr.dylib failed
  - Installing .NET prerequisites might help resolve this problem.
     https://go.microsoft.com/fwlink/?linkid=2063366

This way it will be globally available in your path and can just do it's work!

@pingvinen What would be a good name for the tool when installed globally?

With NPM, I can make a script in my package.json named version. This script will run after changing the package.json version, but before creating the git commit. See order of execution in the NPM version docs.

I would like to see something similar here. I don't know how you would go about implementing it though.

In my specific case, I would like to run a script that versions my Helm charts appVersion with the same value as the .csproj version, and then adds the chart to the same git commit. And I'm sure it could be useful in many other scenarios as well.

As mentioned in #45 tests would be nice to ensure that whitespace preservation is upheld in csproj patching.

If a package has version 1.0.0 and I use the dotnet version 1.0.0 it errors out with "cannot commit" which is a very bad error. Instead the tool should check whether the developer is trying to set the same version as it already is and provide helpful feedback

One possible improvement is to also support label-number in the pre-releases, since I noticed that multiple packages use it (and I do it myself from time to time, not always on purpose).
i.e.,

> dotnet version -f FileParser.csproj --skip-vcs 1.6.1-beta-1
dotnet-version-cli version 2.0.0.0
Bumped FileParser.csproj to version 1.6.1-beta-1

> dotnet version -f FileParser.csproj --skip-vcs prerelease
dotnet-version-cli version 2.0.0.0
ERR Pre-release part invalid. Must be either numeric or `label.number`. Got beta-1

Extending that to labelnumber (beta1, beta2, etc.) would be a nice to have, but I don't know if that would complicate things.

Depends on #33, but let's track them separately so that v2.0.0 can be released without having to decide on this suggestion.

Add support for .NET 5.

Hopefully just a matter of adding an extra TargetFramework to dotnet-version.csproj.

When setting a specific version, it would be awesome to be able to:

• Set a semantic version with pre-release labels (-alpha, etc.).
• Override an existing version that has a pre-release label.

For major, minor and patch behavior could remain the same as it is, not being able to run them successfully if the existing version has a pre-release label.

I just encountered the following error while bumping on a project file that contained no packageId or title:

dotnet-version-cli version 2.1.2.0
ERR Something went completely haywire, developer zen:
        Object reference not set to an instance of an object. STACK: 
   at Skarp.Version.Cli.CsProj.ProjectFileParser.Load(String xmlDocument, ProjectFileProperty property) in C:\projects\dotnet-version-cli\src\CsProj\ProjectFileParser.cs:line 34
   at Skarp.Version.Cli.VersionCli.Execute(VersionCliArgs args) in C:\projects\dotnet-version-cli\src\VersionCli.cs:line 91

The intention of the code-path that failed was to inform the user that the file is malformed, but additional null guards a missing.

Right now if the VersionCli.cs tool or some of the dependencies blow up, the program crashes with the exception.

Handle the exceptions and report back to the user in a nice way

Hi, is there a plan to upgrade this to 3.1?

When you quickly scan your output buffer it can be confusing.

We still want it on the help page, but when it's in "I have fixed stuff mode" it should not be output.

To support the use case where the code should be versioned using a number generated by a CI tool.

sonarqube is now rejecting our analysis because we're using an outdated version of Java in the appveyor image.

This is currently blocking all PRs from building .

Error messages are not written to stderr.

Some CI providers use stderr to detect if a step fails, so currently if a dotnet version invocation fails in one of the steps, that failure may remain unnoticed (such as here).

I just had a case where 1 project in a longer list was still in the 0.x phase. I was bumping majors and did not notice in time that I had now bumped the project to 1.0. This was clearly a mistake on my part, but it made me think that it might be handy if the tool could output a warning or ask for confirmation when bumping the major from 0 -> 1.

The main point of a tool like this is to replace the various scripting hacks to do the same with a crossplatfom tool that works in all environments, so it needs a bit of flexibility:
fx. something like this:

dotnet version --regex-format​="/^(.+).(\d+)$/$1.{fromCommand}-unstable/" --from-command="git rev-list HEAD --count"

1. Reads the version number in the csproj file
2. Counts the number of commits in the repo
3. Replaces the last digit in the version string with the count from before

To make debugging easier if the tool blows up

Since dotnet new classlib does not add <Version> to the csproj file, it becomes a manual process to add the version tag before being able to use dotnet version for the first time.

I think it would make sense to support the case and then defaulting the version to 0.0.0 (before bumping) and perhaps output a warning that there was no version at it was therefore defaulted to 0.0.0 before applying the bump.

I do not think it would be necessary to detect a version set using assembly attributes, as that is basically a different style (and in my opinion an obsolete one with Core) of supplying the version.

Meaning that if you run this in a folder where a .sln is present, parse the given solution to find all the csproj files, and then simply apply the specified bump to all of them (much like we're discussing in #68 ) to make it much simpler to do versioning in "mono repos".

This would mean that the "recursive" option becomes default which is a breaking change, but I think we should leave the -f flag intact so that people can target single files still.

So just like build:

• If we're located in a folder with a .sln file, it will just work
• If there are multiple solution files it has to bail, and you will have to specify which solution file to work on.
• If it is in a folder with a project, it should also just work and apply to that csproj file (which is current behaviour)
• If no csproj if found either, bail, and allow user to specify project file via command line flags

If there are multiple csproj files found due to sln discovery, and there is ambiguity in the version numbers discovered, we can ask the user which version that is the "master" and align the versioning in the csproj files - while respecting non-interactive settings in terminals and simply bail.

Thank you for this awesome tool. It took me quite a little while to figure out the following little details.

1. Escaping $ in yaml files because it is already used by the github actions (or Azure pipelines)

dotnet version patch -m "Auto increment version to v\$newVer by CI/CD pipeline" 

2. Configure git properly before using your tool in a pipeline

git config --local user.email "[email protected]"
git config --local user.name "Your Name" 

Here is my full example script for github pipelines

name: CI/CD
env:
  DOTNET_VERSION_BACKEND: "3.1.x"
  
on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  full:
    name: Build And Publish nuget
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Setup Dotnet ${{ env.DOTNET_VERSION }}
        uses: actions/setup-dotnet@v1
        with:
            dotnet-version: ${{ env.DOTNET_VERSION }}    

      - name: Setup Tool for Version
        run: dotnet tool install -g dotnet-version-cli
      
      - name: Build
        run: dotnet build --configuration Release
  
      - name: Git config
        run: |
            git config --local user.email "[email protected]"
            git config --local user.name "Your Name"         

      - name: Increment version
        run: dotnet version -m "Auto increment version to v\$newVer by CI/CD pipeline" patch

      - name: Pack & push nuget
        run: |
            dotnet pack --configuration Release --no-build --no-restore
            dotnet nuget push bin/Release/*.nupkg --skip-duplicate --api-key ${{secrets.NUGET_API_KEY}} --source https://api.nuget.org/v3/index.json

      - name: Git push changes back to repo
        run: |
            git push
            git push --tags

AppVeyor does not expose secret values on fork PR, we should handle that

I would like to basically to be able to use the version in other places in my build, but the current output formats require a extra work to get it. It would be nice if there was a output format that could print out the version and nothing else. Is there a recommended way for doing this now?

export VERSION="$(dotnet version -f example.csproj)"
echo "$VERSION" # 1.0.0

as a GitLab CI user,
I want to auto generate prerelease version number with MR/PR ID,
so I can keep release version number in config.

MyLibrary.csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <Version>1.2.0</Version>
  </PropertyGroup>

</Project>

current

dotnet-version -d -p "beta" prerelease

ERR Something went completely haywire, developer zen:
	Cannot Prerelease bump when not already a prerelease. Please use prepatch, preminor or premajor

expected

# dotnet-version -d -p "beta" -v $CI_MERGE_REQUEST_IID prerelease
dotnet-version -d -p "beta" -v 66 prerelease
1.2.0-beta.66

$ dotnet version --output-format=json
{"product":{"name":"dotnet-version-cli","version":"2.3.0.0"},"currentVersion":"4.0.0","projectFile":"/path/to/my/clone/src/main/main.csproj"}
Project version is: 
	4.0.0

As far as I can see in the code, the problem is in VersionCli.DumpVersion, which simply continues to the non-json dumping after dumping the json.

I have the following setup:

Common.props

<Project>
  <PropertyGroup>
    <Version>2.0.0</Version>
    <!-- ... a lot more ... -->
  </PropertyGroup>
</Project>

And multiple csproj files like this:
a/A.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <Import Project="..\Common.props" />
</Project>

Changing the version in the Common.props would affect all projects that import this file. This basically allows us that we don't have to maintain n separate csproj file versions.

Trying to use dotnet version with that, I get this:

$ dotnet version -f a/A.csproj
dotnet-version-cli version 2.1.3.0
Project version is: 
	0.0.0

(which is probaby because the Import isn't recognized)

When using Common.props as a "csproj" file, I get this error:

$ dotnet version -f Common.props
dotnet-version-cli version 2.1.3.0
ERR Something went completely haywire, developer zen:
	Not a directory STACK: 
   at System.IO.Enumeration.FileSystemEnumerator`1.CreateDirectoryHandle(String path, Boolean ignoreNotFound)
   at System.IO.Enumeration.FileSystemEnumerator`1.Init()
   at System.IO.Enumeration.FileSystemEnumerator`1..ctor(String directory, Boolean isNormalized, EnumerationOptions options)
   at System.IO.Enumeration.FileSystemEnumerable`1..ctor(String directory, FindTransform transform, EnumerationOptions options, Boolean isNormalized)
   at System.IO.Enumeration.FileSystemEnumerableFactory.UserFiles(String directory, String expression, EnumerationOptions options)
   at System.IO.Directory.InternalEnumeratePaths(String path, String searchPattern, SearchTarget searchTarget, EnumerationOptions options)
   at System.IO.Directory.EnumerateFiles(String path)
   at Skarp.Version.Cli.CsProj.FileSystem.DotNetFileSystemProvider.List(String path) in C:\projects\dotnet-version-cli\src\CsProj\FileSystem\DotNetFileSystemProvider.cs:line 15
   at Skarp.Version.Cli.CsProj.ProjectFileDetector.FindAndLoadCsProj(String bootstrapPath) in C:\projects\dotnet-version-cli\src\CsProj\ProjectFileDetector.cs:line 44
   at Skarp.Version.Cli.VersionCli.DumpVersion(VersionCliArgs args) in C:\projects\dotnet-version-cli\src\VersionCli.cs:line 116
   at Skarp.Version.Cli.Program.<>c__DisplayClass1_0.<Main>b__0() in C:\projects\dotnet-version-cli\src\Program.cs:line 89

It would be cool if the latter would work. If I'm seeing this correctly, it would also be easier than implementing the former because we don't have to resolve import statements and merge their contents into the current project definitions.

Having this would also make a --recursive option unnecessary for me, since I can just update one specific version that is included in all relevant csproj files (see #68).

The above error seems to originate from the csproj check:
https://github.com/skarpdev/dotnet-version-cli/blob/master/src/CsProj/ProjectFileDetector.cs#L38
Changing the file extension to csproj works.

Look here:
https://www.areilly.com/2017/04/21/command-line-argument-parsing-in-net-core-with-microsoft-extensions-commandlineutils/

The CommandLineApplication has sub-command support, and I guess that our different version bumps are actually sub-commands.

The configuration file could include settings like:

• what .csproj to perform version bumps to
• which test-projects to run BEFORE performing the version bump (like npm version does it)
• A commit message template, like : "Creating release %v" and %v is replaced by bumped version

We could call it .version.json or similar.

Enable the CLI to search "upwards" for a config file, i.e we are in src/ when running but the config is stored in the root of the repo.

As mentioned in #45 tests would be nice to ensure that whitespace preservation is upheld in csproj patching.

We should probably consider dropping the not supported dotnet runtimes:

• 2.1
• 2.2
• 3.0
• 5.0

Rather than relying on being in the same directory as the project file.

When using the --message flag to customize the commit message, there is an error and the tag isn't created.

Actual

dotnet-version -f Host.csproj --message 'test'  patch
dotnet-version-cli version 2.1.1.0
ERR Unable to create tag
Usage: dotnet version [options]

Result : There is one commit with "test" message but the tag isn't created

Expected

• Tag is created

Another bug is when using special caracters in the message

dotnet-version -f Host.csproj --message '[skip ci] test'  patch
dotnet-version-cli version 2.1.1.0
ERR Unable to commit

Result : No commit and no tag are created.

Expected

• Commit is done with the custom message
• Tag is created

We are using the Microsoft.NET.Build.Containers package to containerize and push our applications. The image tag is the version from csproj-File. As we need to provide images for multiple architectures we need to deploy multiple tags and build corresponding manifests.

e.g. Version 1.0.1 results in tags 1.0.1-x64 and 1.0.1-arm64 with a docker manifest for 1.0.1 combining those tags.

We aligned with Microsoft Versioning documentation to build the application and provide the Application Version in <VersionPrefix> in csproj and the Suffix in Command-Line resulting in the expected Version.

dotnet publish --os linux --arch x64 -p:PublishProfile=DefaultContainer -p:ContainerRegistry=${{ secrets.ACR_ENDPOINT }} -p:VersionSuffix=x64

See more details on versioning in Blogpost from Andrew Lock.

Unfortunately the dotnet-version-cli does not support Tags <VersionPrefix> and <VersionSuffix>. This would be super helpful to be in line with official csproj-features.

First look at Skarp.Version.Cli.CsProj.ProjectFileProperty points out the missing entries.

Many Thanks for this great project!!!

Once in a while, I'm challenged by by PGP key entry, and I simply cannot enter the code fast enough before dotnet version bails out.

It turns out that GitVcs.LaunchGitWithArgs passes along a wait-timeout of just 1 second to the git command line, and thus it aborts.

I think we can safely increase this to 10 or 20 seconds, to allow people to enter PGP keys or other things that git might ask for, before we fail the version bump.

Hi,

i found dotnet-version-cli in version 2.2.0.0 is returning exit code 0 after an error.

STR:

• edit your code (create pending git changes)
• perfrom "dotnet version..." (it should fail; here: "ERR You currently have uncomitted changes in your")
• check errorcode (should be != 0)

This is a copy of my cmd output

d:\dev>dotnet version  -f path\to_project.csproj patch
dotnet-version-cli version 2.2.0.0
ERR You currently have uncomitted changes in your repository, please commit these and try again
.
.
.
d:\dev>echo %errorlevel%
0

Basically -r|--recursive which will then search from current directory and down, finding all csproj files, and update them to the same version.

Suggestion to keep it simple at first is that the first csproj file found should serve as the "master" version that is used to update the version in all located csproj files.

Perhaps also limit the recursive depth that it searches.

Invoking as:

dotnet version patch -f src/dotnet-version.csproj

Does NOT work, whereas

dotnet version -f src/dotnet-version.csproj patch

Works just fine. It's not a dealbreaker but a nuisance.

dotnet version -m "Auto increment version to v$newVer by CI/CD pipeline" patch
results in "Auto increment version to v0.0.17 by CI/CD pipeline"

dotnet version patch -m "Auto increment version to v$newVer by CI/CD pipeline"
results in "v0.0.17" the default commit message

according the documentation it works for dotnet version minor -m "xxxx".
I think having the possibility tp have the options at the end is good for better readability of the code.