[xperiandri]

Proposed Changes

A review comment on #40 asks that FAKE generates AssemblyInfo.Build.props, imported by src\Directory.Build.props, and that a project updates its specific properties at project level, so that the properties which switch the assembly attributes of the SDK off are not needed (comment). This pull request does that. The other open pull requests are stacked on it. It builds on #41, which is merged: the test project no longer fails at random with FS0073 in the compiler (dotnet/fsharp#20812).

• The GenerateAssemblyInfo target of the build script writes src/AssemblyInfo.Build.props: the properties Product, AssemblyVersion, FileVersion and InformationalVersion from the latest entry of CHANGELOG.md, and the AssemblyMetadata items ReleaseDate, ReleaseChannel and GitHash. It sets IncludeSourceRevisionInInformationalVersion to false, because the git hash is in the metadata, so the informational version stays 1.0.0.
• src/Directory.Build.props imports the file when it exists, and Directory.Build.props no longer sets GenerateAssemblyInfo to false: the SDK generates the assembly attributes from the properties and the items. A project sets what is specific to it in its own project file. The library needs nothing there, because the title defaults to the assembly name.
• AssemblyInfo.fs keeps the module AssemblyVersionInformation with the literals and has no attributes any more. FAKE writes it for every F# project in src. The release commit stages it and AssemblyInfo.Build.props.
• The package Fake.DotNet.AssemblyInfoFile is removed from the build project and from Directory.Packages.props: the target writes the XML itself, and the F# file by a template, because the package cannot write the module without the attributes.
• The README describes the target.

Types of changes

What types of changes does your code introduce to FSharp.Collections.Immutable?
Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

None of these: a change of the build.

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• Build and tests pass locally
• I have added tests that prove my fix is effective or that my feature works (if appropriate)
• I have added necessary documentation (if appropriate)

Further comments

The assembly attributes were listed by reflection on the library of both target frameworks, built before and after this change. They are the same, and the SDK adds four that it generates by default:

Attribute	Value
AssemblyCompany	the authors (Authors in Directory.Build.props)
AssemblyConfiguration	Release or Debug
AssemblyDescription	the package description
AssemblyMetadata	RepositoryUrl, the repository URL (PublishRepositoryUrl is on)

Unchanged: AssemblyVersion 1.0.0.0, AssemblyFileVersion and AssemblyInformationalVersion 1.0.0, AssemblyProduct and AssemblyTitle (FSharp.Collections.Immutable), and the AssemblyMetadata items ReleaseDate, ReleaseChannel and GitHash. Both target frameworks build, and all 2447 tests per target framework pass.

The checked-in files hold the values of the last release (the git hash 59d59515…), as the generated source file did. Running dotnet run --project ./build/build.fsproj -- -t GenerateAssemblyInfo -s writes AssemblyInfo.Build.props and AssemblyInfo.fs again; the result differs from the checked-in files in the git hash only (the one of the current commit). The release run writes them before the release commit.

#40 declares InternalsVisibleTo as a project item. With the SDK generating the attributes the item works as it is, so #40 loses its properties and its target when it is rebased on this pull request.

🤖 Generated with Claude Code