Generate F# assemblyinfo in new fsproj

@KevinRansom

new fsproj should generate assemblyinfo attributes from props.

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

@enricosada

@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

@dasMulli

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

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.

@KevinRansom

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

_CalculateAssemblyAttributes which creates all AssemblyAttribute items.
_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.
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

<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.

@enricosada

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

@enricosada

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

@dsyme

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

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...

@enricosada

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

@dsyme

@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?

@dasMulli

@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.

@dasMulli

@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

Fix dotnet#3113 by porting the relevant roslyn codeand integrate it i…

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

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

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.

This might be affecting #7220

Fix #3113 by porting the relevant roslyn codeand integrate it into th…

Fix dotnet#3113 by porting the relevant roslyn codeand integrate it i…

Fix FCS problem with duplicate ByteFile (#4629)

Navigation Menu

Repository navigation

Generate F# assemblyinfo in new fsproj #3113

65 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Generate F# assemblyinfo in new fsproj #3113

Description

Activity

KevinRansom commented on May 25, 2017

enricosada commented on May 25, 2017

KevinRansom commented on May 25, 2017

enricosada commented on May 25, 2017

dasMulli commented on May 26, 2017

dsyme commented on Jun 19, 2017

dsyme commented on Jun 21, 2017

enricosada commented on Jun 21, 2017

rmunn commented on Aug 7, 2017

dsyme commented on Aug 18, 2017

zvirja commented on Aug 22, 2017

65 remaining items

nguerrera commented on May 23, 2019

rojepp commented on Jun 20, 2019

matthid commented on Jun 21, 2019

realvictorprm commented on Aug 11, 2019

nguerrera commented on Aug 11, 2019

cartermp commented on Aug 21, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions