I never used assembly versions in my .NET Core/5/6 projects until today.
I understand that it can make sense to have different assembly versions loaded into the GAC from time to time, but in my own development process I never use the GAC.
I also read many times that using it is not recommended anymore, because all necessary Dlls will be kept in the local directory of the project.
Therefore my assemblies all have the version 1.0.0.0 and I only use NuGet packages to keep track of the versioning of them.
However, I just read this article and it seems that I should re-think my assembly versions:
What this article states is the following:
❌ DO NOT have a fixed AssemblyVersion.
While an unchanging AssemblyVersion avoids the need for binding redirects, it means that only a single version of the assembly can be installed in the Global Assembly Cache (GAC). Also, the applications that reference the assembly in the GAC will break if another application updates the GAC assembly with breaking changes.
However, only the GAC is mentioned here as a reason.
If I create NuGet Packages for all my libraries and I follow Semantic versioning 2.0 principles, I never had issues with my assembly versions.
Do I need to care about the assembly version, if I never use the GAC?
Assembly version is also part of the assembly identity, which means that when it changes, technically it is considered a different assembly; on .NET Framework you need to hack around that by using "assembly binding redirects" at the application level (via the config); this is awkward and can lead to broken applications - fortunately this is almost entirely a thing of the past in .NET Core / .NET 5+, but: because of this history, many popular public libraries do keep a fixed assembly version, precisely so that it doesn't constantly break .NET Framework consumers - using other assembly attributes to convey the actual full version information.
Short version: in reality, I think you'll be just fine ignoring that advice.