How to determine version or date/time stamp of currently used FSC.exe, FSI.exe and other F# tools in Visual Studio

[abelbraaksma]

More of a question than an issue, but I often find myself wondering what the current version is that I am using in Visual Studio. With multiple branches, nightlies vs RTM releases, multiple PR's often being switched/build all the time and one VS Preview installation, I wonder how I can check this. Thinking of:

• version/date of used FSC.exe, FSI.exe
• version/date of compiler / language service (syntax highlighting, error squigglies)
• anything else

I deliberately mean date here, as I believe version is not updated on each build. I wouldn't mind writing a little script that can be copy/pasted in FSI to query this info, just need to know where to find it by hand.

Showing the logo would perhaps get me closer, but --nologo is the default in VS and cannot be changed I believe.

(edit) This is interesting (works for FSI, and gives a hint on whether the VSIX's installed, but doesn't tell you much about the FSC compiler used for building, which is taken from the SDK paths):

// DO NOT USE: File.GetCreationTime(Assembly.GetEntryAssembly().Location);;
Uri(Assembly.GetEntryAssembly().CodeBase).LocalPath 
|> File.GetCreationTime 
|> sprintf "%A" ;;
val it : string = "13-9-2017 2:05:06"

After doing a VSIXInstaller.exe release\net40\bin\VisualFSharpOpenSource.vsix, I saw the date changing, so that's good. But how to do the same for FSC.exe? I checked internal compiler switches, but nothing yet.

[dsyme]

I think we would normally want this #2323?

[abelbraaksma]

@dsyme, that thread (and its related threads) suggest to somehow lock the github SHA in the metadata of the assemblies. While I think that is a good idea, it wouldn't fully resolve this issue:

• The SHA won't be clear for "normal" users, adding a timestamp would certainly be beneficial
• You cannot access whatever is inside FSC.exe from your code, because your code does not know what FSC.exe is used and cannot magically access it.

The first is easy to solve, just add some more metadata. The second is a tad harder. I would think about a primitive (though not a keyword) which, when used, will return some info of the fsc.exe. This could be the version string, the assembly build date or creation date, or could even be configurable.

But to keep things easy, consider you'd have a primitive compilerVersion() and it would return you an AssemblyName with enough data, then I'd guess that suffices, given that we expand the AssemblyName with something specific for debug builds (i.e., fill the build-number field, for instance).

Even if we expose such member only during development, it would already be beneficial. It took me a week to find out that I wasn't compiling against the new fsc.exe from Visual Studio, and perhaps I was ignorant, but I might not be the only one.

Just a suggestion, perhaps there's an easier way or magic trick.

[KevinRansom]

The File Version field from the details tab is the "official version number".
It doesn't tell what source branch or hash originated it.

The nightlies do not deliver an updated compiler.

The CSC command displays the version number like this, with a detailed version number and the SHA.
Microsoft (R) Visual C# Compiler version 2.3.2.62019 (b7354608)
Copyright (C) Microsoft Corporation. All rights reserved.

warning CS2008: No source files specified.
error CS1562: Outputs without source must have the /out option specified

We should do this for fscd fsi.

[abelbraaksma]

@KevinRansom, yes, that would be great, and thanks for the summary!

But that would be only half way, as still, it would be beneficial to know "from code" what compiler was used (even if it were only to know that running the tests uses the compiler you intended the tests for). Compare, for instance, phpInfo() from PHP (and I still remember that after years not using PHP :p ), though PHP is of course interpreted, so we need to bake it into the compiler with an intrinsic (or what is the word).