Use full version for FileVersion

[i2van]

Assembly/file version is incorrect:

Should be 2.4.0 but 2.0.0 instead.

UPDATE: See this comment for clarification.

[304NotModified]

Hey,

What do you mean? This looks correct to me:

[304NotModified]

2.0.0 instead.

That one will be patched, see <!-- patched in AppVeyor.yml --> in the csproj

[i2van]

ILSpy for different .NET frameworks:

// UtfUnknown, Version=2.0.0.0, Culture=neutral, PublicKeyToken=90217ce7a23260d4

[assembly: TargetFramework(".NETFramework,Version=v4.0", FrameworkDisplayName = ".NET Framework 4")]
[assembly: AssemblyFileVersion("2.0.622")]
[assembly: AssemblyVersion("2.0.0.0")]

[assembly: TargetFramework(".NETCoreApp,Version=v3.0", FrameworkDisplayName = "")]
[assembly: AssemblyFileVersion("2.0.622")]
[assembly: AssemblyVersion("2.0.0.0")]

AssemblyVersion is 2.0.0.0.

[i2van]

<!-- patched in AppVeyor.yml --> seems to be related to next line which is DebugType tag.

[i2van]

Hey,

What do you mean? This looks correct to me:

See Assembly Attributes tab to the right, AssemblyFileVersion field value is 2.0.622

[304NotModified]

AssemblyVersion is 2.0.0.0.

Yes, that correct and on purpose. It's will only change every major version.

AssemblyFileVersion field value is 2.0.622

Also good. It's the build number.

Please explain what you're trying to achieve.

[i2van]

And what is the purpose may I ask? BTW, NLog has correct AssemblyFileVersion number.

[rstm-sf]

@i2van hello!

nuget version != assembly version

assembly version is required for strong name

https://saebamini.com/how-to-version-your-net-nuget-packages-libraries-and-assemblies-azure-yaml-pipelines-example-using-net-core-cli/

[i2van]

@i2van hello!

nuget version != assembly version

assembly version is required for strong name

https://saebamini.com/how-to-version-your-net-nuget-packages-libraries-and-assemblies-azure-yaml-pipelines-example-using-net-core-cli/

Quote from article:

File Version follows the same versioning schema as Assembly Version and has the same limitations, so you can’t use this one for proper SemVer versioning either. But for consistency and preventing user confusion, I recommend keeping the {Major}.{Minor}.{BuildNumber} parts of this attribute in sync with the {major}.{minor}.{patch} from your semantic version.

Combining the above information and after trying many different approaches through the years, I’ve found the below strategy to be at the sweet spot of versioning NuGet packages and .NET assemblies:

Set your NuGet package version to the {major}.{minor}.{patch}-{tag} part of your Semantic Version Follow the SemVer specs for bumping the {major}, {minor} and {patch} parts Set your AssemblyVersion to {major}.0.0.0 Set your FileVersion to {major}.{minor}.{patch}.0

So, the article you mentioned suggests to set FileVersion to {major}.{minor}.{patch}.0 (which is AssemblyFileVersion attribute).

I see no reason for File Version to diverge from Product Version, especially when product consists of single assembly. Besides it's convenient to quick peek on file version during deployment testing without opening file in ILSpy, etc.

[i2van]

Clarification: I suggest changing FileVersion (not AssemblyVersion, thanks for the article), thus I synched title.

[304NotModified]

The file version is synced with the build version. This is great feature, as we know which build produced this output.

Also updating the build version (we do that in NLog, but it's cumbersome and won't be the case in NLog 5)

I don't see really a benefit in changing this to {Major}.{Minor}.{BuildNumber}, and it only will change automatic work to manually (which is error prone)

[304NotModified]

as mentioned, this is by design, nothing goes wrong, and updating every release this version is unneeded and error-prone manual work.