Giter Club home page Giter Club logo

dotnet-setversion's Introduction

dotnet-setversion is a simple .NET Core CLI tool used to update the version information within .NET Core *.csproj files.

It is based on dotnet-gitversion, but is updated to work for the new *.csproj format instead of project.json, and relies on the version information being passed to it.

NuGet Build status

Usage

Install dotnet-setversion as a global tool using the dotnet CLI:

$ dotnet tool install -g dotnet-setversion

If the command completed successfully, you're able to invoke dotnet-setversion in any directory like this:

$ setversion 0.1.2-beta0001

You can also update the version information of a specific project file by invoking like this:

$ setversion 0.1.2-beta0001 MyProject.csproj

Recursive updates

If you happen to have a rather big repo including several project files and you want to update them all at once, you can use the --recursive option.
This will update any project file in and below the current working directory.

$ setversion -r 0.1.2-beta0001

Extracting the version from a file

As well as passing the version directly, you can specify a file to extract the version number from. This is done by prefixing the version argument with an @ symbol. For example, the following command will make the tool try to extract the version from a file in the working directory called "sem.ver".

$ setversion @sem.ver

The file should represent the version either as a simple string (i.e. in the same format you'd ordinarily provide directly to the tool, such as 0.1.2) or in JSON format using a schema like this:

{
  "Version": {
    "Major": 0,
    "Minor": 1,
    "Patch": 2
  }
}

Bear in mind that the JSON format does not support metadata extensions (e.g. -beta0001).

Further notes

For each example, replace '0.1.2-beta0001' with any valid version string or, when having GitVersion installed, with $(GitVersion -ShowVariable NuGetVersionV2) to use your current version automatically.

This (or something similar) can of course be done during a continuous integration build, which is the main intention behind developing this project. This tool depends on itself for its own version management during CI builds, so you can use it as a reference.

Migrating from 1.* to 2.*

dotnet-setversion used to be a per-project tool, but has now been reworked as a .NET Core Global Tool.
As a consequence of this, you have to remove the <DotNetCliToolReference> element referencing dotnet-setversion or you'll get an error when running dotnet restore.

Depending on your build strategy, you have to install setversion once on your build agent (see Usage) or integrate the install command into your build script.

Finally you have to change the way to invoke the program from dotnet setversion to setversion.

dotnet-setversion's People

Contributors

bvandehey avatar paulirwin avatar ryanshores avatar skulblaka avatar stephancasper avatar tagc avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

dotnet-setversion's Issues

Latest dotnet2.0-sdk container doesn't work with setversion

If you get the latest container build of 2.0-sdk from dockerhub, this has stopped working. :-( Any chance of an update?

It was not possible to find any compatible framework version
The specified framework 'Microsoft.NETCore.App', version '2.0.0-preview2-25407-01' was not found.
  - Check application dependencies and target a framework version installed at:
      /

we currently have a hack in our script to "fix" this:

sed -i -e 's/2.0.0-preview2-25407-01/2.0.0/' ~/.nuget/packages/dotnet-setversion/1.0.1/lib/netcoreapp2.0/dotnet-setversion.runtimeconfig.json

AssemblyVersion and FileVersion are not updated.

Let me start by saying this is definitely on the money in terms of solution to the problem.

Having said that, this utility really needs to update the AssemblyVersion and FileVersion too.

I'd propose that you start by changing all 3 at first, and then add parameters to update them all individually if need be.

Cheers

Support for .NET 8

.NET 8 LTS is now generally available, and the tool requires .NET 7 to be installed in a CI environment currently. Updating the project to support .NET 8 will help set it up for the next three years of LTS support.

Support for .NET 5.0

Implement support for .NET 5.0 so that this tool can be used in CI build environments that use this framework.

Support for .NET 7.0

Implement support for .NET 7.0 so that this tool can be used in CI build environments that use this framework.

Allow running "dotnet-setversion" at the solution level

Added the xml snippet to all my csproj files, and get the error message:
No executable found matching command "dotnet-setversion"

I've obviously got something wrong.. Any ideas?

This is VS2017 15.3 preview2 and DotNetCore 2.0 preview 2 csprojs

Support for .NET Core 3.1

I just upgraded to .Net Core 3.1 and noticed that the setversion tool no longer works. After installing, the tool is looking for version 2.1.0 of the Microsoft.NETCore.App framework, but .NET Care 3.1 uses Microsoft.NETCore.App 3.1.1. Will a release for 3.1 be available in the near future? Thanks!

image

Add support for the VSTS dotnet build task

Thanks for writing this CLI. I've been trying to find a good solution to this for a very long time.

The VSTS dotnet build task (v2 preview) supports a custom command that could be used to execute setversion.

image

The issue is that the setversion CLI looks for a csproj in the current directory which does not support the way that VSTS execute dotnet in a build.

The VSTS dotnet build task will identify one or more projects using the glob **/*.csproj. It then passes this as the second parameter to the dotnet CLI. For example:

"C:\Program Files\dotnet\dotnet.exe" setversion C:\B\_work\4\s\MySolution\MyProject.csproj 0.1.0-hostfixes0005

The only way I've been able to dotnet-setversion to work with the current implementation is to use a command line step that executes with the current directory set to the project folder and then call

dotnet setversion 0.1.0-hostfixes0005

The main disadvantage here is that this would require build multiple steps and hard-coded references to project folders to support multiple projects. The build definition then needs to be updated to add more build steps as projects are added to the solution.

One way to solve this would be to identify an absolute path to a csproj in one of the command line parameters and then find the version from one of the other parameters. If no csproj path is specified then the fallback would use what the current implementation does.

Error when running

Hi, I just discovered this, is this still working? I am trying to run this and getting this:

C:\Users\moustafa.el-sawy\OneDrive\Plugins\Combinito\Combinito>setversion 1.1.1 Combinito.csproj
Unhandled exception. System.InvalidOperationException: This operation would create an incorrectly structured document.
at System.Xml.Linq.XDocument.ValidateDocument(XNode previous, XmlNodeType allowBefore, XmlNodeType allowAfter)
at System.Xml.Linq.XDocument.ValidateNode(XNode node, XNode previous)
at System.Xml.Linq.XContainer.AddNodeSkipNotify(XNode n)
at System.Xml.Linq.XContainer.AddContentSkipNotify(Object content)
at System.Xml.Linq.XContainer.Add(Object content)
at dotnet_setversion.Extensions.GetOrCreateElement(XContainer container, String name) in C:\projects\dotnet-setversion\src\dotnet-setversion\Program.cs:line 187
at dotnet_setversion.Program.SetVersion(String version, String csprojFile) in C:\projects\dotnet-setversion\src\dotnet-setversion\Program.cs:line 150
at dotnet_setversion.Program.Run(String version, String csprojFile) in C:\projects\dotnet-setversion\src\dotnet-setversion\Program.cs:line 58
at dotnet_setversion.Program.Run(Options options) in C:\projects\dotnet-setversion\src\dotnet-setversion\Program.cs:line 32
at CommandLine.ParserResultExtensions.MapResult[TSource,TResult](ParserResult1 result, Func2 parsedFunc, Func`2 notParsedFunc)
at dotnet_setversion.Program.Main(String[] args) in C:\projects\dotnet-setversion\src\dotnet-setversion\Program.cs:line 18

Support for .NET 6.0

Implement support for .NET 6.0 so that this tool can be used in CI build environments that use this framework.

Error on Build

I am getting the following error:

No executable found matching command "dotnet-setversion"

in my csproj I have:

Any Ideas? I am building in the microsoft/dotnet:2.0.0-sdk image

Doesn't work for dotnetcore 2.0

If i run this in the microsoft/dotnet:2.0-sdk docker image, I get the following error:

root@79f59544b01b:~/app/implementation/Configuration# dotnet setversion 0.0.1
It was not possible to find any compatible framework version
The specified framework 'Microsoft.NETCore.App', version '1.0.4' was not found.
  - Check application dependencies and target a framework version installed at:
      /
  - Alternatively, install the framework version '1.0.4'.
root@79f59544b01b:~/app/implementation/Configuration#

Building it and targeting netcore2.0 app and packaging it and using that version works, so it's just a matter of targeting both, or possibly even copying the files into a netcore2.0 target platform in the nuget.

Unexpected behaviour in a directory with multiple csproj files

Right now, gitversion uses Directory.EnumerateFileSystemEntries(...).First() to find a file to apply the given version. I would expect execution to fail if there were multiple csproj files in a directory, correlating to other commands like e.g. dotnet build:

>dotnet build
...
MSBUILD : error MSB1011: Specify which project or solution file to use because this folder contains more than one project or solution file.

TeamCity integration?

I use TeamCity. I wonder if there is a way to use this without changing any of the csproj files.

CI build hangs indefinitely

All Appveyor builds have recently started hanging indefinitely when executing this line:

cd src/dotnet-setversion; dotnet setversion $env:VERSION; dotnet pack -c Release -o release/; cd ../..

Specifically, dotnet setversion $env:VERSION seems to be the issue. The build logs display "Setting version: x.x.x.x" as expected, but the build never progresses beyond this point.

RDP'ing into the build server while a build is running shows this happens with both PowerShell and Command Prompt. Trying to execute dotnet setversion 1.2.3-4 in one console and displaying the contents of dotnet-setversion.csproj in another shows that the version field is getting updated as expected, but that the file also gets prepended with <?xml version="1.0" encoding="utf-8"?> (which does not happen when executing the same command locally).

Support to modify VersionPrefix and automatically increment a specified portion of the semantic version

I'm looking at using this as a part of CI around nuget packages, and currently use VersionPrefix to build release versions based on build dates etc.

so

<VersionPrefix>3.1.0.1</VersionPrefix>

will produce ci builds of 3.1.0.1-ci-<YYYYMMDDBB>

What I'd like to be able to do is say ok I want to publish a release version, and have that just be incrementing 3.1.0.1 by one minor version and publish it as such, and then continue to build additional postfixed builds from that.

I'd think that would require first being able to use this to specify which version to update (VersionPrefix vs Version) and then also be able to tell it to increment so I don't have to know exactly what the prefix version is., just tell it to incremement minor or something.

Does this seem like reasonable functionality to add to this project?

Does not handle multiple <PropertyGroup> tags

If csproj file has multiple <PropertyGroup> tags and any of them but first have the <Version> tag, the tool will not detect it and instead will create a new <Version> tag inside of the first <PropertyGroup> tag even though a subsequent <PropertyGroup> tag already has a <Version> tag set. For example:

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

In above example, the tool will create a new <Version> tag inside of the first <PropertyGroup> tag instead of updating the <Version> tag inside of the second <PropertyGroup> tag.

Working with older project formats

I wonder, does this tool work with the older .NET Framework project files? I seem to be getting errors when using older csproj and vbproj files.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.