AssemblyVersion inconsistant across TFMs

[CZEMacLeod]

Description

I'm not sure if it is by design or not, but I recently tripped up because the AssemblyVersion was not consistent across the different TFMs for some of the Microsoft.Extensions.* packages.

Looking at e.g Microsoft.Extensions.Logging.Abstractions and Microsoft.Extensions.FileProviders.Abstractions specifically, but I imagine it applies to most if not all packages built this way.

When there are multiple dlls supplied for different TFMs (net8.0, net9.0, net10.0, netstandard2.0, net462) the AssemblyVersion attribute does not match between them.

e.g.

// S:\.nuget\packages\microsoft.extensions.logging.abstractions\10.0.5\lib\netstandard2.0\Microsoft.Extensions.Logging.Abstractions.dll
// Microsoft.Extensions.Logging.Abstractions, Version=10.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
[assembly: AssemblyFileVersion("10.0.526.15411")]
[assembly: AssemblyInformationalVersion("10.0.5+a612c2a1056fe3265387ae3ff7c94eba1505caf9")]
[assembly: AssemblyTitle("Microsoft.Extensions.Logging.Abstractions")]
[assembly: AssemblyMetadata("RepositoryUrl", "https://github.com/dotnet/dotnet")]
[assembly: AssemblyVersion("10.0.0.0")]

// S:\.nuget\packages\microsoft.extensions.logging.abstractions\10.0.5\lib\net10.0\Microsoft.Extensions.Logging.Abstractions.dll
// Microsoft.Extensions.Logging.Abstractions, Version=10.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
[assembly: AssemblyFileVersion("10.0.526.15411")]
[assembly: AssemblyInformationalVersion("10.0.5+a612c2a1056fe3265387ae3ff7c94eba1505caf9")]
[assembly: AssemblyTitle("Microsoft.Extensions.Logging.Abstractions")]
[assembly: AssemblyMetadata("RepositoryUrl", "https://github.com/dotnet/dotnet")]
[assembly: AssemblyVersion("10.0.0.0")]

// S:\.nuget\packages\microsoft.extensions.logging.abstractions\10.0.5\lib\net462\Microsoft.Extensions.Logging.Abstractions.dll
// Microsoft.Extensions.Logging.Abstractions, Version=10.0.0.5, Culture=neutral, PublicKeyToken=adb9793829ddae60
[assembly: AssemblyFileVersion("10.0.526.15411")]
[assembly: AssemblyInformationalVersion("10.0.5+a612c2a1056fe3265387ae3ff7c94eba1505caf9")]
[assembly: AssemblyTitle("Microsoft.Extensions.Logging.Abstractions")]
[assembly: AssemblyMetadata("RepositoryUrl", "https://github.com/dotnet/dotnet")]
[assembly: AssemblyVersion("10.0.0.5")]

Reproduction Steps

Use ILSpy or similar to decompile the .dll file from the nuget file downloaded from nuget.org.

Check the assembly name, and the AssemblyVersion attribute.

Expected behavior

I would expect the AssemblyVersion to be consistent across all the DLLs and only be incremented if the assembly has changes per SemVer rules.

Actual behavior

The AssemblyVersion in net4x appears to reflect the release - e.g. 10.0.0.5 in the package version 10.0.5, but is 10.0.0.0 in the other TFMs.

Regression?

No response

Known Workarounds

No response

Configuration

Net 10 SDK. VS2026.

Other information

No response

[MihuBot]

I'm a bot. Here are possible related and/or duplicate issues (I may be wrong):

• Inconsistent AssemblyVersion of Microsoft.Extensions.Logging.Abstractions between .NET and .NET462 runtime#109044
• Microsoft.Extensions.Logging.Abstractions 9.0.8 Nuget Assembly Version mismatch for different targets runtime#119386
• Inconsistent assembly version for System.Text.Json netstandard2.0 runtime#64003

[CZEMacLeod]

Read through these and it seems like this is intentional.
I'm not sure I understand the logic to be honest.
The argument is something around the 'inbox' versions having to had the same assembly version as the base version of .net (e.g. net10.0 => 10.0.0.0 instead of the servicing version 10.0.0.5).
However, these are in the nuget package, not inbox, and should surely have the newer version such that they take precedence over and shared runtime that may be installed - almost the same reasoning as the net4x and GAC?