Good day fellas! After quite some time never in touch with .NET code for a longer period of time, it's time for me to release extension methods that I have been using, with a twist. I'm releasing in conjunction of the latest version of .NET Core so that it will be usable in every application you might want to build (Windows, Linux, Android, iOS).
The main reason for this method was started when I code extensively with String.Format, but always fail to remember which index the exact object is located. String.Format does need you to specify which index of the object you want to format, and in most cases if you fail to remember, you could end up in error or wrong formatting.
When you want to start working on .NET Core Class Library, the first thing you would want to worry about is the attributes of the project you're working on. One of those things is versioning. It's always been a complicated ordeal because typically you want to version your work automatically.
There are many ways to version your class library, from utilizing the CI/CD components, or as simple as empowering your project file to do that for you automatically. This post will help you with the latter.
Creating .NET Core Class Library Project
To create a .NET Core Class Library project, you can follow the PowerShell commands below.
md dotnet-lib
cd .\dotnet-lib\
dotnet new sln --name dotnet-lib
dotnet new classlib --name MyLibrary --framework net6.0 --language C#
dotnet sln add MyLibrary\MyLibrary.csproj
Those commands will get you up quite easily in terms of creating the project, or you can use Visual Studio of any version (Community, Enterprise, or any latest versions).
Add Version Logic into the Project File
Once you're done with creating, now it's time to modify the project file. Now, here's something that's debatable in the sense of how you want to version your project. One might say you shouldn't version based on the date and time and stick with the traditional way of versioning, but I wouldn't mind if that will keep me focus on what I should do.
//standard versioning
1.2.4039
//{manual-major}.{manual-minor}.{build-count}
//date and time versioning
2022.11.21.1159
//{year}.{month}.{day}.{hour-minute}
In a real-world scenario, some people work on multi-projects that could take away our focus that would end up giving the wrong version, that's total madness. But each to their opinion by the way, and you should take a part when discussing versions about to take place.
Edit your MyLibrary\MyLibrary.csproj file, you should see something similar to the below code.
net6.0
enable
enable
Still inside the Project element & below the PropertyGroup, add the following code.
What this UsingTask element does is to create a custom code function within your project file, and that function will return the auto-generated version as an output. So, to make things clearer, the task name in this example is SetVersionNumber that accepts 1 input parameter of CreationYear and 1 output parameter of GeneratedVersion.
As we put this task, it won't do anything until we attach the task to certain build targets. put the following code just below that UsingTask element.
$(GeneratedVersion)
Now, this Target element does execute sequentially of all elements within. There are 3 major sections of elements: executing SetVersionNumber task and output as GeneratedVersion variable, then output a Message to the build console, and then finally set the different version artifacts from GeneratedVersion variable.
That's it!
Your final code of csproj file may look like this below.
And your generated Class Library after build will look like this below.
Conclusions
This is definitely one of the ways, the easier and you don't need to work too much to define your version. You just need to set this once and forget for all other times, gives you more focus on what you're doing.
I'll talk more about how you can combine this with NuGet packaging and publishing via GitHub Actions.
