Assembly Version not listed

[TheAngryByrd]

Description

Currently the libraries do not generate Assembly versions.

Error messages, screenshots

Assembly info "0.0.0.0"

Failing test, failing github repo, or reproduction steps

Can test with (typedefof<Foo>.GetTypeInfo().Assembly.GetName().Version.ToString())

Expected Behavior

Version info is embedded in the assembly

Known workarounds

It doesn't look like you can easily pass it on the CLI dotnet/sdk#1098 so we might need to just generate the AssemblyInfo with FAKE instead of the dotnet autogenerate. Or modify the fsproj (I'd rather not).

Other information

• Operating System:
  • windows [insert version here]
  • macOs [insert version]
  • linux [insert flavor/version here]
• Platform
  • dotnet core
  • dotnet full
  • mono
• Branch or release version:

[TheAngryByrd]

Or maybe we can set it via cli https://stackoverflow.com/a/45426330/890736

[TheAngryByrd]

Or maybe not. dotnet/fsharp#3113

Might need to just use FAKE to generate them.

[rmunn]

Note that dotnet/fsharp#3113 has now been fixed, and will appear in a future .Net Core 2.1 preview (which will, AFAICT, have version number 2.1.200-preview-something). So it might be possible to do dotnet --version in the build script and, if the version number reported is >= the version where the bugfix appears (whatever that version ends up being), use the cli tools to set it. That would be another way to reduce Git churn with AssemblyInfo.fs files being constantly updated (#61).

[TheAngryByrd]

I was wondering when that would get fixed.

I guess we have a couple questions to answer:

• Should we always just support the latest release of the sdk so we don't have to have so many pivot points in the build script or template? Obviously this makes our job easier to maintain this but do dotnet core users typically stay on older versions anyway? If they do they usually pin in global.json per repository.

• Should we let msbuild handle the assemblyinfo generation or just always do it outside like we are currently?

  1. I'm typically scared of a script editing the .xxproj file since I've seen many tools just introduce bugs and leave .xxproj files in weird states.
     a. If we go the msbuild route We might be able to get away with a .props file that we tell people is auto generated. This would give me higher confidence.
  2. I did add some other pieces of metadata like ReleaseData, GitHash, ReleaseChannel https://github.com/TheAngryByrd/MiniScaffold/blob/master/Content/build.fsx#L166-L170. Are these something we can tell msbuild to add? Should we even be adding them? I find them useful in my projects but I'm only one data point.

[rmunn]

Since .Net Core 2.0 released without this feature, the scaffold will probably have to support that for a while. I don't know enough .Net Core users yet to know what they'll do, but I think while dropping support for .Net Core 1.1 is fine, .Net Core 2.0 will need to be supported for quite some time.

As for the "msbuild or outside tool" question, I don't have a solid opinion yet. I feel like we should go through the msbuild tool as much as possible since that's what other .Net developers seem to expect, but that's just a vague feeling with no specific data to back it up. I do agree that modifying .xxproj files directly should be avoided if possible, as there are too many possible variations where your modification might not make sense for the way project XYZ is set up. A .props file, with "This file is auto-generated" comments, sounds like a good idea to me. (And maybe the comments could point to how to change them "properly", e.g., "Edit build.fsx and change the AssemblyInfo target if you want to modify this file").

But there's a certain elegant simplicity to just creating an AssemblyInfo.fs file too... I'll have to think about this one before I'm certain of what I would suggest.

[TheAngryByrd]

I'm being stupid we a can pass these properties to msbuild. No need to modify a file.

[TheAngryByrd]

So I guess the next question is, pivot on the template or the build script? I'd like the keep the build script clean but that means figuring out how to use the templating engine to do this and properly test it in travis/appveyor.

[rmunn]

Could use a condition in the template.json file to detect the currently-installed dotnet version, and then copy a different build script into the template based on the detected dotnet version. E.g., if dotnet version is before 2.1.100 then copy "make-assemblyInfo-build.fsx" into the "build.fsx" file, but if if dotnet version is after 2.1.100 then instead copy "use-msbuild-build.fsx" into the "build.fsx" file. See https://github.com/dotnet/templating/wiki/Reference-for-template.json (though that document does not specify which environment/MsBuild variables will contain the current dotnet version).