How to autoincrement version number for a stand alone VB Class Library? (VS 2022, .NET 6)

Question

I'm trying to design a REST API Service and Client that shares a common library (set of public classes that the Service and Client both reference).

This common library is a stand alone VB Class Library with some basic class/struct definitions that both the REST API Service and Client would reference.

I want to be able to autoincrement the build version number on this common class, so that when it builds the dll, the version is tagged in the name of the dll (for example: api-common-classes-1.1.0.dll, api-common-classes-1.2.0.dll, etc).

Then I would upload these dlls to a shared drive, and use a shell script in the pre-build step of the other projects to download the appropriate dll and reference it in the other solutions. (In the future I would prefer to upload these to artifactory and pull them down from there using MSBuild Artifactory plugin, but baby steps for now).

Here is a simple diagram illustrating what I'm looking to accomplish.

Dependency / Build Diagram

Researching this online, I see posts mentioning the use of AssemblyInfo class and Text Template to change the version number. However it appears that it is not possible to generate an AssemblyInfo class with a class library project.

In Java Gradle/Maven world, this is a fairly simple task to accomplish (build and version jar, publish somewhere, reference this jar in another project). However in .NET world this is fairly obscure to figure out.

What is the recommended way to accomplish this task?

Answer 1

I think what you need is not to generate a DLL that has a version number but a NuGet package (that anyway has a version number) and that you publish to a file share that is included in your NuGet sources.

And then the idea of auto-incrementing the version number is obsolete as you want to give a speaking number for each change (increase of major = breaking change, increase of minor = addition of new types/methods/properties without changing the existing interface, increase of patch = bug fixes, adjustments in documentation etc. that does not change the interface at all).

Here a template of a project file that generates NuGet packages on build:

<Project Sdk="Microsoft.NET.Sdk">

    <PropertyGroup>
        <TargetFrameworks>net6.0;net5.0;net48</TargetFrameworks>
        <Configurations>Debug;Release</Configurations>
        <EnableNETAnalyzers>true</EnableNETAnalyzers>
        <AnalysisMode>AllEnabledByDefault</AnalysisMode>
        <GenerateDocumentationFile>true</GenerateDocumentationFile>
        <!-- Set <major>.<minor>.<patch>.0 for the package version according to the following logic: -->
        <!--    1.2.3.0  =>  1.2.4.0  if no interface changes have been performed (patch, bug-fix) -->
        <!--    1.2.3.0  =>  1.3.0.0  if new interfaces have been added (feature release) -->
        <!--    1.2.3.0  =>  2.0.0.0  if existing interfaces have been modified (breaking changes) -->
        <Version>1.0.0.0</Version>
        <!-- Set to <major>.<minor>.0.0 of the <Version> element -->
        <AssemblyVersion>1.0.0.0</AssemblyVersion>
        <!-- Set to <major>.<minor>.<patch>.0 of the <Version> element -->
        <FileVersion>1.0.0.0</FileVersion>
        <Authors>you</Authors>
        <Company>your company</Company>
        <Copyright>Copyright (C) 2022 by your company</Copyright>
        <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
        <!--<PackageIcon>metadata\Icon.png</PackageIcon>-->
        <Description>Speaking description of the library (package)</Description>
        <PackageReleaseNotes>Speaking description of the current change.</PackageReleaseNotes>
        <PackageTags></PackageTags>
    </PropertyGroup>

</Project>

To make it a bit more interesting, it compiles the library as .NET 4.8, .NET 5.0 and .NET 6.0 into the package.