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?

[KevinRansom]

@zvirja yeah ... sorry about this ... it slipped through the cracks.

[KevinRansom]

@enricosada, let me know if you want me to take care of this.
Also, If you want to push a WIP PR I can push it the last 100 yards.

[cmeeren]

In a .NET Core 2.0 console app, I've set the assembly version in the project properties, but when building with VS, the version is always missing (0.0.0.0). Is this caused by the issue described here?

I'm currently working around this by explicitly adding

[<assembly: System.Reflection.AssemblyVersionAttribute("2.0.0.0")>]

[zvirja]

@cmeeren Yep, that's because of this issue.

@dsyme @KevinRansom Do you know if it will be fixed somewhere soon? The VS 2017 update 5 did a great step towards the unification, while this issue still makes us to feel the difference between different SDKs.. 😕

[atlemann]

I have been struggling with this issue for days not getting the assembly info attributes in my compiled .dlls for F# projects. Will this be fixed? I'm running dotnet cli 2.1.3. Guess I'll have to do it the F# ProjectScaffold style for now.

[JonCanning]

I'm doing this in my build script for now

printf "\n[<System.Reflection.AssemblyVersion \"$ASSEMBLYVERSION\">] do()" >> ./src/Config.fs

[atlemann]

Hmm..seems that using the ProjectScaffold FAKE script's AssemblyInfo step does not work when building F# projects with dotnet CLI either.

[haf]

Registering my interest here, too, from #3549 (comment)

[edud69]

This seems to be fixed in VS 2019.

[lfr]

Fixed as in a file is generated with new projects or fixed as in the contents of the Assemblyinfo file (version, icon, etc) are properly handled?

[atlemann]

VS2017 on the left, VS2019 on the right

[matthid]

@atlemann It was reported above that building within Visual Studio fixes the problem.
Issue is building with the SDK on the command line. Can you clarify that this is what you have tried?

The problem only happens in the dotnet-core runtime based compiler. Visual Studio runs the full-framework based one. (At least that was the state in VS2017)

[atlemann]

@matthid You're right.

.NET Core SDK: 2.2.204

Using dotnet build from CLI:

Building the same project using VS2019:

[KevinRansom]

@ there is an issue with the coreclr compiler, that it generates the attributes fine, however, it doesn't embed them as a resource in the resource fork. This is a known limitation of the F# compiler for coreclr, it is a fair sized amount of work to make it work and so it will be addressed when priorities allow.

Kevin

[dasMulli]

@atlemann can you try a 3.0 preview CLI (even when building for < 3.0)? The new build tasks in the CLI copy over resources from the dll file to the apphost executable when building on windows machines.

[nguerrera]

@dasMulli I believe the issue is that the dll won't have the resources in the first place when compiled with the F# compiler running on .NET Core.

[rojepp]

@dasMulli I still see this issue in 3.0.100-preview6-012264 using dotnet publish/dotnet build.
Building from VS does work.

I also wanted to note that passing in version as a property does not work either: dotnet build /p:FileVersion=1.1.0

[matthid]

I've sent a PR for this, so I hope we can finally get this sorted out. I understand this has low priority but it disturbs me every time I see it and makes it harder for people - especially for newcomers - to figure out version related issues... I have seen this several times

[realvictorprm]

So the FileVersion thingy still needs to be fixed if I understand correctly?

[nguerrera]

I commented on the PR: #7024 (comment)

It seems there's a misunderstanding about work for managed resources becoming useful for this problem when they are actually separate.

[cartermp]

This might be affecting #7220