folkerkinzel / incversion

.NET Core 3.1 console application, that increments the AssemblyFileVersion of a Visual Studio 2019 Sdk-style project automatically every build.

IncVersion

Increments the <FileVersion> property in the Visual Studio Project File automatically after every build. It can be used in Visual Studio 2019 projects on Sdk-style project files.

Download IncVersion

IMPORTANT: On some systems, the content of the ZIP file is blocked. Before extracting it, right click on the ZIP file, select Properties, and click on the Unblock button - if it is present - in the lower right corner of the General tab in the Properties dialog.

How it works

After every build of your project, IncVersion increments - by default - the Build part of the current <FileVersion> property in your Visual Studio Project File, but you can set it to increment the Revision part instead with the command line argument --revision. If your Visual Studio Project File didn't have a <FileVersion>-Property before the build, IncVersion will add <FileVersion>1.0.0.0</FileVersion> to it.

You might wonder, why IncVersion does not change the Visual Studio Project File before Visual Studio compiles the output? Unfortunately, it is impossible, because Visual Studio reads the <FileVersion> from the project file before it executes any Build Events. In order to clarify this behavior, I decided for myself to prefer the Post Build Event rather than the Pre Build Event.

Why doesn't IncVersion increment the Assembly Version or the Nuget Package Version? That's why only yourself knows, if the current build is an important or breaking change to your application or not. Different version numbers describe different aspects and they don't need to be identical.

Set up IncVersion

1. Make sure to have the .NetCore 3.1 runtime installed on your computer

IncVersion is a very small platform-independent .NetCore-3.1-dll with no runtime components included. That's a design choice, because - following my approach - IncVersion is copied to every Visual Studio solution directory. Therefore it's necessary to have the runtime installed global.

2. Download the zip-File with IncVersion and unzip it to the solution directory of your project

Download IncVersion here and unblock it, if your computer blocks it. (See description above.)

Unzip it to the directory, where the solution file (*.sln) of your project is. ("Right-click and select "Unzip all".) The solution directory now should look like this:

• < YourSolutionDirectory
• • □ YourSolution.sln
  • < IncVersion
  • • □ IncVersion.dll
    • □ IncVersion.runtimeconfig.json
    • □ README.txt
  • < YourProjectDirectory
  • • □ YourProject.csproj

Notice: You have to unzip IncVersion to every solution directory, where your project is referenced - otherwise the Post Build Event will fail (resulting in a build error), if you try to build your project from there!

3. Give your project a Post Build Event to invoke IncVersion

To invoke IncVersion, you have to add a Post Build Event to every Visual Studio project that you want IncVersion to increment the FileVersion property. Choose only projects, that are physically located in the same project directory, where you unzipped IncVersion in the previous step.

To add a Post Build Event, right-click the project in Visual Studio Solution Explorer and select "Properties". In the project properties window select "Build Events".

To increment the Revision part of the FileVersion property, paste the following code to the textbox "Post Build Event":

if $(ConfigurationName) == Release if '$(TargetFramework)' == 'netcoreapp3.1' dotnet $(SolutionDir)IncVersion\IncVersion.dll $(ProjectDir)$(ProjectFileName) --revision

(If you want to increment the Build part instead, remove --revision at the end.)

The Post Build Event MUST NOT contain any line-breaks!

If you have an earlier Post Build Event, make a line-break at the end of the earlier Post Build Event and paste the code to the new line.

Replace netcoreapp3.1 in the Post Build Event with one of the build targets of your project, if NetCore 3.1 is not among them. To find the correct naming of the build target, open your Visual Studio Project File in the text editor: The build target is the content of the property <TargetFramework>. If it's a multitargeting project, the build targets belong to <TargetFrameworks>: Choose one!

The post build event explained:

• if $(ConfigurationName) == Release causes IncVersion to be invoked only if you build the Release-Configuration. You may remove this, if you like - in addition - also to count the debug builds.
• if '$(TargetFramework)' == 'netcoreapp3.1' causes IncVersion to be called only ones per build - even if you have more than one build target. If you have only one build target (and plan never to have a second), you can remove this.

FAQ

Can I assign the file version independently when using IncVersion?

Of course, you can: Because of that IncVersion changes the project file after the build, the current build takes the file version number, that you have entered in the project file immediately before the build.

It becomes a little bit tricky, if you use the "Publish" function of Visual Studio. For a workaround, read the next question.

How to get a FileVersion-Build-Part with value 0 when publishing a .NetCore app?

Visual Studio calls the Build Events twice, if you right-click to your project in Visual Studio Solution Explorer and choose "Publish". If have set IncVersion to increment the Build part, you have to set a file version number with only two parts before you publish.

For instance: Setting FileVersion to 1.3 before publishing, produces assemblies with a FileVersionAttribute, that has the value 1.3.0.0 .

When using IncVersion to increment the Revision part (command line argument --revision), you can have a three-part-version number before publishing.

For instance: Setting FileVersion to 1.3.14 before publishing, produces assemblies with a FileVersionAttribute, that has the value 1.3.14.0 .