zoltu / zoltu.versioning Goto Github PK

View Code? Open in Web Editor NEW

9.0 3.0 4.0 75 KB

NuGet package for automatically versioning a project with git.

License: Creative Commons Zero v1.0 Universal

C# 100.00%

zoltu.versioning's Introduction

Zoltu.Version

NuGet package for automatically versioning a project with git.

Usage

Install the NuGet package (https://www.nuget.org/packages/Zoltu.Versioning/).
Remove AssemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion attributes from your AssemblyInfo.cs (if you have them).
Add VersionAssemblyInfo.cs to your version control system's ignore mechanism (e.g., .gitignore).
When you want to increase the major or minor version numbers, tag the commit that should bump the version with v#.#
Example Tag: v3.5
Note: If you are using a build server that automatically builds on commit, it is recommended that you tag before pushing to the remote master. This is because your build server will kick off without that tag and therefore the build that is generated will not have the newly tagged version.
You can also add a tag in the form v#.#-string to generate a special informational version attribute on the assembly. This is useful for NuGet prerelease packages.

Versioning

The versioning system is simple, and designed to follow semantic versioning for CI/CD projects more or less. When a build is kicked off, a VersionAssemblyInfo.cs file is generated (no need to add it to your project, it is compiled in automatically). The VersionAssemblyInfo.cs file contains AssemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion assembly attributes.

The first step to figuring out the version is getting the git repository. This is done by traversing the directory tree until a valid .git folder is found. If none is found then the version is 0.0.0.0.

The second step is to walk the commit history from HEAD to the first commit, looking for a tag with a name that matches v#.# (the actual regex is ^v(\d+).(\d+)$). If such a tag is found, then the number of commits traversed are counted to generate the patch version and the major and minor versions are parsed from the tag.

Example

action	version	info version
tag `v1.2`	`1.2.0.0`	`1.2.0.0`
commit 3 times	`1.2.3.0`	`1.2.3.0`
tag `v1.3-RC`	`1.2.3.0`	`1.3.0.0-RC`
commit 3 times	`1.2.6.0`	`1.3.0.0-RC-003`
tag `v1.3`	`1.3.0.0`	`1.3.0.0`

Note: The build version never changes because in the .NET world it is ignored.

Leaving some versions out of the generated file

You may want to only have AssemblyVersion auto-generated, or perhaps leave out the AssemblyVersion. This can be done with each of the three version attributes by setting the relevant variables in the .csproj file.

<PropertyGroup>
	<GitVersionIncludeAssemblyVersion>false</GitVersionIncludeAssemblyVersion>
	<GitVersionIncludeAssemblyFileVersion>true</GitVersionIncludeAssemblyFileVersion>
	<GitVersionIncludeAssemblyInformationalVersion>true</GitVersionIncludeAssemblyInformationalVersion>
</PropertyGroup>

The above XML in your .csproj file will result in an assembly version file like this (note the missing AssemblyVersion):

[assembly: AssemblyFileVersion("3.5.10.0")]
[assembly: AssemblyInformationalVersion("3.5.10.0")]

Skipping revision and build parts

It is possible to instruct the versioning system to output only a version consiting of only major and minor. This can be done with each of the three version attributes independently by setting relevant variables in the .csproj file.

<PropertyGroup>
	<GitVersionOnlyMajorAndMinorInAssemblyVersion>true</GitVersionOnlyMajorAndMinorInAssemblyVersion>
	<GitVersionOnlyMajorAndMinorInAssemblyFileVersion>false</GitVersionOnlyMajorAndMinorInAssemblyFileVersion>
	<GitVersionOnlyMajorAndMinorInAssemblyInformationalVersion>false</GitVersionOnlyMajorAndMinorInAssemblyInformationalVersion>
</PropertyGroup>

When the first is set to true as in the above example the output attributes will be as shown below.

[assembly: AssemblyVersion("3.5.0.0")]
[assembly: AssemblyFileVersion("3.5.10.0")]
[assembly: AssemblyInformationalVersion("3.5.10.0")]

NCrunch Integration

NCrunch builds will start failing after adding this project to your solution due to being unable to find LibGit2Sharp libraries System.IO.FileNotFoundException: Could not load file or assembly 'LibGit2Sharp, Version=0.18.1.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified. To work around this, add the following to your .ncrunchsolution file:

<AdditionalFilesToInclude>packages\Zoltu.Versioning.*\build\**.*</AdditionalFilesToInclude>

zoltu.versioning's People

Contributors

Stargazers

Watchers

Forkers

tuyndv phpn00b jamsoft cje2002

zoltu.versioning's Issues

Two tags, one commit.

If you have two tags pointing at the same commit, a crash occurs.

question about code contracts

I see you use Code Contracts. Would you be willing to share your experience? Would you recommend using them, in particular for a project that should be compatible with Mono?

thank you

msbuild properties to choose which attribute to write

Sometimes, we need to keep control over AssemblyVersion attribute and let others be generated.
Adding some msbuild properties to control which attribute is written out would allow this scenario and others combinations.

<PropertyGroup>
   <GitAssemblyVersion>false</GitAssemblyVersion>
   <GitAssemblyFileVersion>false</GitAssemblyFileVersion>
   <GitAssemblyInformational>false</GitAssemblyInformationalVersion>
</PropertyGroup>

Get the version from Git.

Currently, the version is hard coded to 1.2.3.4. This should be changed to use Git. The most recent tag in history matching the pattern v\d_.\d_ should be used as the major.minor version. The patch version should be the number of commits since that tag (with 0 being the same commit as the tag). Revision is always 0 since .NET ignores it for versioning.

Would be nice to see a possiblity to set the ApplicationVersion and MinimumRequiredVersion?

Since we are deploying with click onve it would be nice to have a possibility to set these properties with the same version the assemblyinfo will be patsched.

Attribute conflict in Azure Functions project

When trying to use this on a project using Azure Functions, the build fails on the second time it is called (i.e. when the VersionAssemblyInfo.cs file exists). I have to manually delete the file every time.

NETSDK1022
Duplicate 'Compile' items were included. The .NET SDK includes 'Compile' items from your project directory by default. You can either remove these items from your project file, or set the 'EnableDefaultCompileItems' property to 'false' if you want to explicitly include them in your project file. For more information, see https://aka.ms/sdkimplicititems. The duplicate items were: 'Properties\VersionAssemblyInfo.cs'

This is what is on my csproj file:

<PropertyGroup>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <AzureFunctionsVersion>v2</AzureFunctionsVersion>
    <GenerateAssemblyInfo>false</GenerateAssemblyInfo>
  </PropertyGroup>

I can fix the build by adding <EnableDefaultCompileItems>false</EnableDefaultCompileItems>, but then no Functions are recognized when running.

Enhance informational version

We're using the versioning to produce a package published on NuGet.

What do you think about a way to extend the AssemblyInformativeVersion with a NuGet prerelease suffix.

I was thinking to optionally extend the tag pattern to match something like v3.0-alpha4. The alpha4 suffix would be appended to the informative version.

[assembly: AssemblyVersion("0.3.0.0")]
[assembly: AssemblyFileVersion("0.3.40.0")]
[assembly: AssemblyInformationalVersion("0.3.40.0-alpha4")]

Separate AssemblyVersion and AssemblyFileVersion

Is there a way to us the tag for AssemblyVersion and the calculated version for AssemblyFileVersion? I mean that for 10 commits ahead of tag v2.3 the attributes would be

[assembly: AssemblyVersion("2.3")]
[assembly: AssemblyFileVersion("2.3.10.0")]

Also why is there a 0 at revision. Would it be fine to omit that bit entirely?

Contracts are violated.

Time needs to be spent bringing the contracts up to date. Currently, there are a number of contracts that cannot be proven by the static analyzer.

Generated file is not added to project automatically.

Currently, the user must add the generated assembly file to their project.

The assembly file should be compiled into their project in a way that doesn't require the user know about its existence. Since we already have a .targets file, the easiest solution is likely to just have the .targets file have an ItemGroup with the file in it. I believe this will cause it to be built.

TeamCity integration (output version to log)

Would love to have TeamCity integration possible:
http://hadihariri.com/2016/08/22/Git-Versioning/#passing-information-to-teamcity

Which would just mean outputting "##teamcity[buildNumber '${version}']" to the log

Package origin question

By the way, I first found your package when I was looking for a way to version my project. Only recently I've discovered the similar https://github.com/ParticularLabs/GitVersion project, which has beenaround for a bit over a year.

Were you aware of it when you started Zoltu.Versioning?

Prerelease version improvement

I've been happlily using the prerelease feature I asked you for before and I've just realized there's a gotcha.

For example for 10 commits ahead of tag v1.3-alpha the version would be 1.3.10.0-alpha. Now when the tag v1.3 is created the version 1.3.0.0 is actually lower then the prerelase.

My conclusion is that when a prerlease tag is found the commits ahead count should be actually appended to the end (best left padded to three or four digits) and not included in the main number. With such improvement the above prerelease would be 1.3.0.0-alpha010 and thus logically correcty according to SemVer.

Tom