4

I have a .NET 5.0 console application. How can I create a version resource and then display that version in my application?

In the past, I have seen an AssemblyInfo.cs file. But I don't see anything like that in my new project.

Jonathan Wood
  • 65,341
  • 71
  • 269
  • 466
  • You don't need a *resource* for this. Version information is specified through [various project properties](https://andrewlock.net/version-vs-versionsuffix-vs-packageversion-what-do-they-all-mean/) in the project file. The properties can be overridden by passing explicit values in eg `dotnet build`. It's also possible to use expressions to calculate eg date-based values. I use `$([System.DateTime]::UtcNow.ToString(`yyyyMMdd-HHmm`))` for this reason – Panagiotis Kanavos Jun 15 '21 at 15:18
  • 1
    The duplicate isn't correct. There's no need to create AssemblyInfo.cs to specify version attributes. That's done in `csproj` – Panagiotis Kanavos Jun 15 '21 at 15:24
  • @PanagiotisKanavos [The duplicate](https://stackoverflow.com/questions/42138418/equivalent-to-assemblyinfo-in-dotnet-core-csproj) I marked this of mentions csproj methods of specifying the version. This question is a duplicate of that one, and if there are additional ways that it can be solved beyond the existing answers, then the answers should be added on that one. – mason Jun 15 '21 at 15:51
  • 1
    @mason it's not a good duplicate. Most of the answers there show how to generate `AssemblyInfo.cs`, not how to use project properties. That includes the accepted answer with 381 upvotes. Only people that already know the answer would realize the *correct* answer is [this](https://stackoverflow.com/a/49601178/134204) – Panagiotis Kanavos Jun 15 '21 at 15:53
  • @PanagiotisKanavos [This answer](https://stackoverflow.com/a/42143079/1139830) shows the csproj technique. If you have additional information, then that should be edited into the existing answers on that question, or a new answer posted on that question. This question is still a duplicate of that question. – mason Jun 15 '21 at 15:55
  • @mason that's why this is a bad duplicate. That's the *sixth* answer. How would anyone realize that's the correct answer, when most of the previous ones say `generate assembylinfo`? A good duplicate, like a good answer, should be able to stand by itself, not require explaining why the answer isn't the answer – Panagiotis Kanavos Jun 15 '21 at 15:58

1 Answers1

5

I had to solve this problem recently: how do you know which version of a tool is deployed? And how can you automate the version number, so you don't accidentally use an old version?

In the past, that information was stored as attributes in AssemblyInfo.cs. In .NET Core, those attributes are now generated by project properties at runtime.

Andrew Lock explains how the various properties like Version, VersionPrefix, VersionSuffix,AssemblyVersion FileVersion, PackageVersion, InformationalVersion are used.

The most important ones are Version, VersionPrefix and VersionSuffix. That's because Version is used as the default for the other ones. Version in turn can be calculated as VersionPrefix-VersionSuffix if there's no explicit value.

Quoting the article:

The Version property is the value most commonly set when building .NET Core applications. It controls the default values of all the version numbers embedded in the build output, such as PackageVersion and AssemblyVersion so it's often used as the single source of the app/library version.

If you use System.Commandline, the version info displayed by --version is the InformationalVersion whose default comes from Version.

The default VersionPrefix is 1.0.0 and the default suffix is empty, resulting in version 1.0.0.

*Formulas

The nice thing is that the properties can have formulas. I was able to automatically generate a date-related version number simply by adding this to a csproj that contains no other version information

<VersionSuffix>$([System.DateTime]::UtcNow.ToString(`yyyyMMdd-HHmm`))</VersionSuffix>

Each time I build my tools now I get versions like 1.0.0-2021061501836

Overriding the properties

The project values can be overridden during build, either by specifying an explicit version suffix, or specifying an explicit value for the project properties, eg :

dotnet build --configuration Release --version-suffix preview2-final

Or

dotnet build --configuration Release /p:Version=1.2.3-preview2-final

This way, an automated release pipeline can specify a new version that overrides anything set in the project file

Panagiotis Kanavos
  • 120,703
  • 13
  • 188
  • 236
  • Thanks, that's too bad there is no auto increment built in. I'm not sure I like the looks of your date suffix approach. Also, I'm not very clear on how the version usually changes from 1.0.0. – Jonathan Wood Jun 15 '21 at 16:22
  • 1
    @JonathanWood you can set `Version` directly, or `VersionPrefix`. As for autoincrement, you'd have to store the old version somewhere *and* commit it to source control - otherwise the build server won't know what to increment. That can be messy. An incrementing value doesn't tell you a lot about the build either. It's common to use the short git has as a suffix, eg `0.1.11-g0c85fbc` which tells you which commit the application was built from and actually search git for it. – Panagiotis Kanavos Jun 15 '21 at 16:53
  • Excellent answer to the first part of the question the answer to the other part "and then display that version in my application?" is: Assembly.GetEntryAssembly().GetCustomAttribute().InformationalVersion – Darren J. McLeod Aug 11 '22 at 14:22