FyneApp.toml section for Windows metadata

[jflamy]

Checklist

• I have searched the issue tracker for open issues that relate to the same feature, before opening a new one.
• This issue only relates to a single feature. I will open new issues for any other features.

Is your feature request related to a problem?

Please add support for additional metadata to match what can be set in a windows Executable. A full rc file would contain the values below.
Alternately, allow adding a .syso file and detect that it is present, and if so, don't create a duplicate resource issue.

VS_VERSION_INFO VERSIONINFO
FILEVERSION 1,0,0,0
PRODUCTVERSION 1,0,0,0
{
    BLOCK "StringFileInfo"
    {
        BLOCK "040904E4"
        {
            VALUE "FileVersion", "1.0.0.0\0"
            VALUE "ProductVersion", "1.0.0.0\0"
            VALUE "OriginalFilename", "example.exe\0"
            VALUE "FileDescription", "Example Application\0"
            VALUE "InternalName", "example\0"
            VALUE "CompanyName", "Example Company\0"
            VALUE "ProductName", "Example Product\0"
            VALUE "LegalCopyright", "© Example Company. All rights reserved.\0"
            VALUE "LegalTrademarks", "Example™\0"
            VALUE "Comments", "This is an example application.\0"
            VALUE "PrivateBuild", "\0"
            VALUE "SpecialBuild", "\0"
        }
    }
}

Is it possible to construct a solution with the existing API?

No. There is a conflict (dual resources) if rsrc or other is used to construct a syso

Describe the solution you'd like to see.

Let me provide the syso, or simpler for users, add these keys to FyneApp.toml

[andydotxyz]

Much of that is output already - can you clarify what is not working?

I can see copyright, trademark and comments as the main ones I think?

[jflamy]

The FyneApp.toml documentation only shows 3 being set.
https://docs.fyne.io/started/metadata.html

Probably that some fields are duplicated in several places. But there is a reason they are separate in Windows. Some version fields have four sections, other three. This affect how windows perceive the versions.

The main ones missing are the company name, copyright, file description, and comments

[andydotxyz]

But there is a reason they are separate in Windows. Some version fields have four sections, other three. This affect how windows perceive the versions.

Yes and we handle all of this for you. Specifying every field for every OS is not what we want to do - mostly it can be deduced from the information at a basic level.

Please try building with the metadata in place and compare the output with your desired outcome rather than just listing the fields you think we should include for a 1:1 mapping.

[jflamy]

When you have semantic versioning with -alpha -beta -rc you need to distinguish them in the version number as far as Windows is concerned, otherwise you can't tell which version is newer. So yes, it's all version 1.9.3 but it's not the build number either. Typical workaround is to use 100+alphanumber, 200+betanumber and so on, as a fake third number, but that ugliness is only needed on Windows.

[andydotxyz]

In which field is that? In the docs it lists file version and product version as 4 integers separated by "." IIRC.

[jflamy]

The fourth field is ignored actually. It is by convention used for a build number but that's just convention -- many people leave it as 0 always. Conceptually, the build that gave you version 1.9.1 could be build 5195 and the file version would be 1.9.1.5195

But determine which version should supersede another, only the first 3 fields are used. So when doing semantic versioning with alpha and beta etc. you end up fabricating the third field in both product version and file version. You end up with funny numbers like 1.9.1101 for alpha01, 1.9.1203 for beta 03 etc. and something like 1.9.1400 for the actual release, etc.

I'm creating both the program and it's installer (InnoSetup) in a GitHub Actions workflow, and it's convenient to be able to use a uniform scheme with something that is very much Window-oriented (the installer) and the app inside.

(aside) there is already a LinuxBSD section in FyneApp.toml so the precedent for having Windows-specific warts could be said to have been set.

[andydotxyz]

Using version number and build surely fulfils the need you expressed? We want to support a) all platform requirements and b) semantic versioning. This fits in with Go versioning rules so in this case it's a case of lowest common denominator sorry.

(aside) there is already a LinuxBSD section in FyneApp.toml so the precedent for having Windows-specific warts could be said to have been set.

Yes there is - which is what we would replicate for any windows specific data, that is why I was asking about what fields are not already accounted for.

[jflamy]

I want to be able to use the current Version with a human readable string 1.9.1-beta01 semver.

Windows also needs numerical-only version numbers. Windows installers follow the Windows OS practice of using the first 3 digits of the ProductVersion and FileVersion to decide whether to update. In a product delivered as several files, a ProductVersion is applied to all files in the product, and a FileVersion is applied to each file. For an exe executable both are usually set to be the same.

Generic -- Human-readable

Version = "1.9.1-beta02"

Windows-specific for Windows installers

The two version fields would be, for the first 3 digits, a mapping of the semver with some convention for the 3rd number so that the installer knows that 1.9.1-beta02 supersedes 1.9.1-beta01 (in the following example, 202 is the numerical mapping of beta02,

FileVersion = "1.9.1202.0"
ProductVersion = "1.9.1202.0"

Generic additions -- These could all be pulled in an "About" pop-up.

The names below are the Windows one. They could be changed for the toml (ProductDescription -> Description) and mapped to the Windows name when injected.

ProductDescription = "Control Panel for the owlcms application"
CompanyName = "Lerta Consulting Inc."
ProductName = "owlcms Control Panel"
LegalCopyright = "© 2025-Present Lerta Consulting. All rights reserved.\0"
LegalTrademarks = "owlcms™"
Comments = "Application to start/stop/update the owlcms server.\0"

[andydotxyz]

Your description does not match what I have read in the Microsoft docs https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.fileversioninfo.productversion?view=net-9.0

" Typically, a version number is displayed as "major number.minor number.build number.private part number". A product version number is a 64-bit number that holds the version number as follows: "

Can you point me to what I am missing? I can't see best practice that describes having two different version formats.