Generate F# assemblyinfo in new fsproj

[enricosada]

new fsproj should generate assemblyinfo attributes from props.

ref dotnet/netcorecli-fsc#93

• in dotnet/sdk is done in the language agnostic target Microsoft.NET.GenerateAssemblyInfo.targets#L93-L96 using the WriteCodeFragment task
• atm the F# language is not implemented, so doesnt generate the file with attributes
• the WriteCodeFragment is defined inside Microsoft/msbuild and contains a version with CodeDom and another for coreclr (just doing stringbuilder), and support both c# and vb

As a note i tried to add the F# in the same way as C#/VB, but atm PR was stopped for a design decision
dotnet/msbuild#2132 (comment) /cc @KevinRansom @cartermp

[KevinRansom]

@enricosada

To do this for the SDK we can override in our targets file and sdk apps will work fine.

https://github.com/dotnet/sdk/blob/8204b6b1f3ff2f9717c5d66ab903795271de2e9c/src/Tasks/Microsoft.NET.Build.Tasks/build/Microsoft.NET.GenerateAssemblyInfo.targets#L51

But we should also send a PR to the dotnet sdk refactoring the current implementation a bit.
@nguerrera said he would welcome a PR that improved this :-)
The bit where the attributes are generated should be moved to a new target: GetAssemblyAttributes or some such name.
And then : CoreGenerateAssemblyInfo just handles the write.
We can override CoreGenerateAssemblyInfo to write the attributes with a build task added to the Microsoft.FSharp.Build library ... or something.
Does that make sense?
Enrico,

thanks for pushing on this, it's really great that you take the time to dive into all of the stuff.
Kevin

[enricosada]

Does that make sense?

Yes, didnt know a refactoring effort was needed or ongoing, but is getting better. love to override only what's needed 👍

Let's wait a bit for new @dasMulli PR ( from dotnet/msbuild#2132 (comment) ) seems that refactoring is in progress already

There's already dotnet/sdk#1007 which splits the target into _CalculateAssemblyAttributes and CoreGenerateAssemblyInfo but it probably won't land in its current form (see PR discussion. I'll be sending out a PR today for an alternative implementation)

Meanwhile i'll prepare a task to write the file to be added in Microsoft.FSharp.Build because attrs need escape checks anyway.
Cannot be done with msbuild target alone afaik, sigh why msbuild property functions are so limited, when i need just a string -> string and some % transformation).

So as your said we'll need to just override CoreGenerateAssemblyInfo later, i'll PR soon, meanwhile copying the current CoreGenerateAssemblyInfo from sdk to check is everything working ok end2end

[KevinRansom]

Actually I was referring to the dotnet sdk rather than an msbuild refactoring. And it’s only a tiny refactor just enough to get the attributes separate from what we need to implement in an override.

[enricosada]

@KevinRansom yes @dasMulli is doing that with dotnet/sdk#1255

1. _CalculateAssemblyAttributes which creates all AssemblyAttribute items.
2. _CreateGeneratedAssemblyInfoInputsCacheFile creates an obj/tfm/projectname.AssemblyInfoInputs.cache file containing the hash of all AssemblyAttribute items. This filename is available as $(GeneratedAssemblyInfoInputsCacheFile). The target uses msbuild 15's WriteOnlyWhenDifferent="True" feature for WriteLinesToFile so the file doesn't change unnecessarily.
3. CoreGenerateAssemblyInfo which generates the projectname.AssemblyInfo.cs file, using the cache file as input for incremental build.

The _CreateGeneratedAssemblyInfoInputsCacheFile is transparent for us

we will override just CoreGenerateAssemblyInfo to generate the file from AssemblyAttribute items.
i'll send a PR for that, you can assign this to me

[dasMulli]

<Target Name="CoreGenerateAssemblyInfo"
        DependsOnTargets="CreateGeneratedAssemblyInfoInputsCacheFile"
        Inputs="$(GeneratedAssemblyInfoInputsCacheFile)"
        Outputs="$(GeneratedAssemblyInfoFile)">

Should now do the trick, the $(GeneratedAssemblyInfoInputsCacheFile) input is only to trigger the target on incremental builds if any attribute changes but the file's contents can be ignored.

[dsyme]

@enricosada @KevinRansom Where are we with this - does it have to be done for the SDK work to count as feature complete? thx

[dsyme]

@enricosada @KevinRansom ping... (I'm trying to clarify the status of all the "Urgency Now" bugs)

[enricosada]

@dsyme i half finished it, i hope one or two days

[rmunn]

I recently found SuaveIO/suave#635 (assembly version should be 2.1.1.0 but is coming out as 0.0.0.0 when built with the dotnet core CLI tools -- when built with the .Net Framework tools or the Mono tools the assembly version is correct). At first I thought that was caused by an incorrect build step in the Suave project. But could that bug possibly be getting caused by this one? If the project is specifying the assembly version, but it's not making it into the DLL because of this bug, that would also explain the symptoms I'm seeing.

I'm completely lost when it comes to the .NET Core build system at the moment -- too many changes that I haven't been able to find documentation for -- so it's entirely possible that I'm barking up the wrong tree. But the fact that this bug is still open does make me wonder...

[dsyme]

@enricosada @KevinRansom ping... (I'm trying to clarify the status of all the "Urgency Now" bugs)

[zvirja]

@dsyme @enricosada @KevinRansom Thank you guys for working on this one! happy to that I'm not the only one who have spotted it 😉

I'd say that this is very important (or even critical) issue as it breaks unification between C# and F#. Our solution contains both csproj and fsproj projects and currently I need to handle all fsproj files separately in the build scripts and patch their assembly info files manually.

Is there any chance that this issue will be resolved in the nearby future, so build scripts could be much simplified?