Setting the version number for .NET Core projects - CSPROJ - not JSON projects

Question

This question is very similar to Setting the version number for .NET Core projects, but not the same. Using the latest stable version of .NET Core at the time of writing (1.

Answer 1

What I do is this in .csproj

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <Deterministic>false</Deterministic>
    <AssemblyVersion>2.0.*</AssemblyVersion>
  </PropertyGroup>
</Project>

Specify the wildcard in AssemblyVersion and then turn off Deterministic flag. Numbers will be added for the wildcard.

Answer 2

As I've answered here, I've made a CLI tool called dotnet-setversion which you can use for versioning *.csproj-style .NET Core projects.

During a CI build, you can use GitVersion or another tool to determine a version number for your project and then invoke dotnet-setversion $YOUR_VERSION_STRING in your project root directory.

Answer 3

MsBuild 2017 will generate some assembly info if you missing them in Project file.

If you can read the msbuild target file you can look at:

[VS Install Dir] \MSBuild\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.GenerateAssemblyInfo.targets

You will see you can use some property in you project file to disable generated assembly info to prevent duplicated with your generated tools.

• <GenerateAssemblyInfo> (This property will on/off all generate assembly info)
• <GenerateAssemblyCompanyAttribute>
• <GenerateAssemblyConfigurationAttribute>
• <GenerateAssemblyCopyrightAttribute>
• <GenerateAssemblyDescriptionAttribute>
• <GenerateAssemblyFileVersionAttribute>
• <GenerateAssemblyInformationalVersionAttribute>
• <GenerateAssemblyProductAttribute>
• <GenerateAssemblyTitleAttribute>
• <GenerateAssemblyVersionAttribute>
• <GenerateNeutralResourcesLanguageAttribute>

Answer 4

I use Jenkins + Octopus for CI, and following worked quite well:

1. Have a pre-build Powershell script that can take CI build number as a param or default to something preset.
2. Have a separate nuspec file in the project for CI.
3. The pre-build script would update nuspec file with the latest build version.
4. Publish project with Jenkins.
5. Call Nuget manually with a nuspec file from #2.
6. Push the nuget package to Octopus.

Answer 5

For those looking for a different automated (CI) way to do this, consider using conditionals in the .csproj file based on environment variables. For example, you might normally have a hardcoded version prefix and a timestamp-based suffix. But for proper releases, you would want to replace both with a single version that you set during the CI build. To do this, you can set an environment variable before calling dotnet build: let's say, RELEASE_VERSION.

In the .csproj file, under a <PropertyGroup>, you would have the following:

<Version Condition="'$(RELEASE_VERSION)' != ''">$(RELEASE_VERSION)</Version>
<VersionPrefix Condition="'$(RELEASE_VERSION)' == ''">0.0.1</VersionPrefix>
<VersionSuffix Condition="'$(RELEASE_VERSION)' == ''">$([System.DateTime]::UtcNow.ToString(`yyyyMMdd-HHmm`))</VersionSuffix>

The conditions above are set up such that, if the environment variable RELEASE_VERSION is empty, the normal prefix and suffix tags are used. But if it's not empty, then the signular version tag is used instead.

Answer 6

You can override any property from the command line by passing /p:PropertyName=Value as arguments to dotnet restore, dotnet build and dotnet pack.

Currently, Version composition works as this: If Version is unset, use VersionPrefix (defaults to 1.0.0 if unset) and - if present - append VersionSuffix.

All other version are then defaulted to whatever Version is.

So for example you can set <VersionPrefix>1.2.3</VersionPrefix> in your csproj and then call dotnet pack --version-suffix beta1 to produce a YourApp.1.2.3-beta1.nupkg (if you have project reference that you want the version suffix to be applied to as well, you need to call dotnet restore /p:VersionSuffix=beta1 before that - this is a known bug in the tooling).

Of course, you can use custom variables as well, see this GitHub issue for a few examples.

For a complete reference of supported assembly attributes, i suggest looking at the source code of the build logic here (the values surrounded with $() are the properties used). And since i'm already talking about the source, this is the logic that composes the version and a few other properties.