Feature request: command-line version

[haf]

I'd like to supply assembly version info using the command line and not have to generate a file.

Use-case is to provide a build step for Container Builder and allow me to attach a git commit hash to the assembly metadata (not necessarily a numeric)

Requirements:

• Support passing a numeric build number that can be used for assembly redirects
• Support passing a tag value, such as from what branch the dll was built
• Support passing the git commit hash or the like
• All of the above through MsBuild since it seems everything goes through MsBuild nowadays.

[KevinRansom]

@haf

It is already exists in the compiler, however, it is deprecated. We currently have no plans to remove it, and it should work with the coreclr compiler too.

As always, it is deprecated and may eventually get removed.

c:\temp\fsc>fsc --version:1.2.3.4 program.fs
Microsoft (R) F# Compiler version 4.1
Copyright (c) Microsoft Corporation. All Rights Reserved.

warning FS0075: The command-line option '--version' has been deprecated

If the warning bothers you try this:

c:\temp\fsc>fsc --version:1.2.3.4 --nowarn:75 program.fs
Microsoft (R) F# Compiler version 4.1
Copyright (c) Microsoft Corporation. All Rights Reserved.

c:\temp\fsc>

[haf]

Great! I suppose I can pass the git hash there then?

[haf]

I think I prematurely closed it. I've updated the initial question with details on what's needed.

[KevinRansom]

The dotnet sdk attribute generation for F# is not wired up yet. Once it is wired up you will just add an

<InformationalVersion>The rain in spain</InformationalVersion>

Build the test to contain whatever you need. There will be no command line mechanism to pass this. The sdk does a good job of passing it through.

This sets the System.Reflection.AssemblyInformationalVersionAttribute which is used for this stuff. It will show up as the productversion in explorer.

[dsyme]

Will close as a duplicate of #3113

[haf]

@KevinRansom But that (the xml tag) means I have to modify the file on disk, right? Why not support it from command line?

[dsyme]

@KevinRansom But that (the xml tag) means I have to modify the file on disk, right? Why not support it from command line?

I personally agree that supporting these on the command line makes total sense

However we follow the rule "do what C# does" here. It doesn't have command line switches. For F# the deprecated --version is very ancient (before we started following this rule) but we still allow it.

[haf]

Pardon my ignorance. Why follow C#? Would it break something to also allow it to come from command line?

The use-case is to be able to use the above mentioned tooling; and I don't have xml parsers and generators on the linux command line (that I know of). (But possibly if FAKE grew a CLI I could use the fake:latest future docker image to do it)

[dsyme]

Pardon my ignorance. Why follow C#?

Because doing it differently comes with large cost, e.g. in .NET SDK tooling, IDE tooling, anything which processes project files or generates assembly information files (FAKE).

Would it break something to also allow it to come from command line?

Offering an alternative way of doing the same thing is ok though since F# 2.0 we avoided it unless we were totally sure we were bringing differentiate value. It's just work (implementing it, checking for duplicate information, testing etc.)

[haf]

Can't we use this issue to track this feature request – specifically from command line – and when the time comes and the --version flag has been harmonised with the XML tags, I can add --informational-version besides that as a PR to this repo, including tests?

It would be very useful in all my nugets and it would be used very much. As example of how much it would help; all PRs to my projects, Suave, Expecto, Logary, HTTP.fs and so on, to implement support for .Net Core has failed to include the auto-generated AssemblyInfo.fs file, despite remembering the command-line version flag. Had that version flag traversed all the way to the compiler, (when wired up), we wouldn't have had the tens of people asking why assembly redirects with Suave didn't work (thereby providing some of them a bad initial experience to F# dev).

[dsyme]

@haf But wouldn't those PRs have used the technique from #3113 to specify the version? We would encourage that, even if it means modifying the file (or presumably passing a /p:InformationalVersion=... , flag to msbuild or dotnet). Having all the command line flags just creates "two ways to do things", assuming you're using the dotnet/msbuild tools to build

[haf]

If I manually have to modify the file, it is not what I'm after.

If I can call dotnet or whatever and THAT modifies the file; it's fine. Is that the technique?

[dsyme]

@haf If I understand correctly, using dotnet build /p:InformationalVersion=... should do the trick, once #3113 is done. No files would be modified (except one generated behind the scenes somewhere - I'm not sure where). But @KevinRansom and @enricosada can confirm

[haf]

I think this bug should be re-opened since it's not solved for mono which is the latest stable toolchain we're using, and #3113 is about the .Net Core SDK. Neither <InformationalVersion>, <AssemblyInformationalVersion> nor the command line flag work in this case.

Use case:

 - name: eu.gcr.io/$PROJECT_ID/fsharp
   waitFor: ["fsharp-restore", "js-build-langs"]
   id: fsharp-build-1
   args:
   - msbuild
   - /verbosity:minimal
   - /p:Configuration=Release
   # https://cloud.google.com/container-builder/docs/configuring-builds/substitute-variable-values
   - /p:InformationalVersion=v2.0.0-alpha.$SHORT_SHA
   - Api.sln

[cartermp]

Based on the updated issue text + @haf's sample dockerfile I'll re-open this.

@KevinRansom and @dsyme can you confirm if there would be any additional work beyond using /p:InformationalVersion= once #3113 is finished? If there isn't, then let's migrate @haf's requirements over there (and place them in the issue text) and re-close this issue.

@haf just to give you some perspective on timing, we're full steam ahead on the remaining work for Type Providers and F# Interactive on .NET Core, aiming for the 2.1 release which will be in Q2 2018. There are some higher-priority things to finish first (such as #4034) in addition to that, so while I'd like to say we could get this in for 2.1, the conservative side of me says not to count on it.

[haf]

@cartermp No worries, I can wait; I've done a workaround for now that involves environment variables. It feels good to have an open issue to track the problem with.

[haf]

Would be great to get this feature :) 👍

[KevinRansom]

This feature is not likely to happen, the .NET Sdk has good support for configuring these values. and the .NET Sdk is the long term direction that we are aiming at for project file configuration, Mono too is heading that way.

Kevin

[cartermp]

Just to clarify here, Mono is moving towards using the .NET SDK as well, so we just have one tool set and project file format for cross-platform (which does support this use case now). Any work independently of that would be an interim solution that would eventually end up in the bucket of legacy-we-need-to-support-but-wish-we-didn't-have-to, or something to eventually phase out with deprecation warnings, which is also additional work.

[haf]

Thank you for clarifying your aims further. Just to make it even clearer; are you saying I can pass the version to dotnet build as a command line argument or that that is planned?

[KevinRansom]

Like this:

C:\Users\kevinr\source\repos\ConsoleApp18\ConsoleApp18>dotnet build ConsoleApp18.fsproj /p:InformationalVersion="HeyKevin"
Microsoft (R) Build Engine version 15.8.166+gd4e8d81a88 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 25.53 ms for C:\Users\kevinr\source\repos\ConsoleApp18\ConsoleApp18\ConsoleApp18.fsproj.
C:\Users\kevinr\source\repos\ConsoleApp18\ConsoleApp18\obj\Debug\netcoreapp2.1\ConsoleApp18.AssemblyInfo.fs(13,69): warning FS2003: The attribute System.Reflection.AssemblyInformationalVersionAttribute specified version 'HeyKevin', but this value is invalid and has been ignored [C:\Users\kevinr\source\repos\ConsoleApp18\ConsoleApp18\ConsoleApp18.fsproj]
  ConsoleApp18 -> C:\Users\kevinr\source\repos\ConsoleApp18\ConsoleApp18\bin\Debug\netcoreapp2.1\ConsoleApp18.dll

Note the error message says that the specified value is invalid. This happens because the use any string fix, is not yet in released product.