4

Previous answers to this question refer to editing the AssembyInfo.cs file to set the Assembly Version. I am generating a NuGet package using the new leaner .Net Core format of .csproj file for .Net Framework 4.6.1, and there is no AssemblyInfo.cs (or it's auto-generated and deleted).

If I try to set the Package Version property to 1.0.2.* in the project properties in VS2019, I get a popup error:

A wildcard ("*") is not allowed in this field

If possible, how can I get the revision number to auto-increment, ideally so on each build the number is incremented (1.0.2.45 => 1.0.2.46) and the number is retained across releases (1.0.2.46 => 1.0.3.47, manually editing the build/release number).

Note: I've already looked at the answer here, here and here and they all refer to the AssemblyVersion attribute. I want to update the Package Version (which is simply the Version in the CSProj file).

Update: One of the answers suggested a couple of GIT versions tools. I forgot to mention that TFS is used for a lot of the projects I want to use this on; these are work projects shared with other team members and are well established so could not easily be migrated to GIT without a lot of discussion even if it didn't get a simple veto by management as an unnecessary change.

StarNamer
  • 650
  • 1
  • 11
  • 27

2 Answers2

4

First, on wildcards in assembly and package versions:

The wildcard for assembly (not package) versions is discouraged from being used - the new default for "sdk-style" projects use a compiler feature called "deterministic build" which aims to produce a binary identical output for every time the same unchanged source code is compiled. This mode does not allow for wildcards in assembly versions, which would change every 2 seconds.

However, this feature can be turned off by setting

<PropertyGroup>
    <Deterministic>False</Deterministic>
</PropertyGroup>

If you then use a wildcard in your assembly version, the compiler will update your version based on the current time.

To re-use this assembly version for the package version, you need to add some additional build logic to your project file as described here: MSBuild /t:pack Nuget-Package has always the same Version

What I encourage to do:

A lot of projects use their git history for versioning, incrementing the version based on the git commit count.

I suggest looking into tools like Nerdbank.GitVersioning (lightweight and easy to use) or GitVersion (more features and better documentation) that allow you to configure how your versions can be automatically derived from the branches/tags that are being built.

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Martin Ullrich
  • 94,744
  • 25
  • 252
  • 217
  • 2
    I reasd about "deterministic build" and understood the reason for it. But am surprised no-one has encountered the need to automatically increment the version when a change *is* made. At the moment, to test a change in a package, I have to make the change and then update the assembly and package version numbers to ensure that it gets seen as a new version even if it's in a local repository. I wouldn't have thought I was the first person to want a VS extension to automate this. The Git version tools probably aren't that useful to me, since I'm using TFS. – StarNamer Apr 07 '19 at 12:35
  • Similar things can be done vor TFVC changest numbers but manually.. But there aren't a lot of tools since TFS supports Git and there are build tasks for it that parse GitVersion for example. You could also use your build definition to increment a version that is stored somewhere. – Martin Ullrich Apr 07 '19 at 15:09
  • Thanks,We are moving to Git for new projects, but I was hoping someone had already put something together for TFS to save my having to do it! – StarNamer Apr 07 '19 at 22:49
  • 1
    @StarNamer Seen this? https://github.com/devlooped/GitInfo – Dai Jan 25 '22 at 05:35
2

There's no auto increment support for versioning nuget packages. You need to figure out/set the version number manually (or programmatically) through something like msbuild, a continuous integration platform, or third party tool.

mariocatch
  • 8,305
  • 8
  • 50
  • 71