Add version information to RuntimeInformation.FrameworkDescription.

[Priya91]

No description provided.

[mellinoe]

nit: I think you don't technically need the ToString() call because string.Format will do it for you.

[mellinoe]

Also, should we cache that version? Probably doesn't make a whole lot of difference, but I don't think there's any way it could change during runtime

[stephentoub]

If we're going to cache something, presumably it could be the whole FrameworkDescription result.

[Priya91]

Here there is no call to OS apis, and hence didnt cache, as this operation is relatively simple. I will cache the whole thing as well, although for future coding practices, how do you decide when to cache and when not to? the lifetime of the string is going to be more instead of when it was a local. So the tradeoff will be between execution time and memory. But here both are insignificant.

[stephentoub]

for future coding practices, how do you decide when to cache and when not to?

Based on expected / measured usage patterns. If you expect this method to only be invoked rarely, then caching doesn't make sense: the string object(s) will be allocated once and the work to compute those strings done once, and then there's no need to hold onto them and take up space in the process after that. If you instead expect this method will be used repeatedly, then it makes more sense to cache rather than doing the work and allocating each time. And if you expect it to be used really frequently, on a hot path, with every operation mattering, you might even choose to initialize the static as part of its declaration rather than lazily in the property so as to avoid branching costs to check for whether it's been initialized.

For this specific case, it definitely won't fall into the last case. And I doubt it even falls into the middle case. More than likely, caching here is unnecessary. I was simply commenting that if something made sense to cache, it would be the result of the whole operation rather than just the version used in the operation.

[stephentoub]

LGTM

[Priya91]

@dotnet-bot Test Innerloop Ubuntu Release Build and Test

[eerhardt]

Does "Version" always have the build version number in it? I thought that is what the "FileVersion" attribute was for?

[Priya91]

"Version" holds the build version. Here, am getting the version of the dll holding object, so it should have a value.

[eerhardt]

I don't have the absolute latest code on my Linux machine, but when I run:

    static void Main(string[] args)
    {
        Console.WriteLine(typeof(object).GetTypeInfo().Assembly.GetName().Version);
    }

I get the output:

4.0.0.0

This seems less useful to me.

[Priya91]

The FileVersionInfo apis to get the FileVersion are not available on .NET Native. This is the best I could find, that will work for all platforms. Let me know if I am missing any other APIs that can be used here.

[eerhardt]

Can't you get the FileVersionAttribute from the assembly using Reflection APIs? And then use it to get the version string.

If that isn't possible, I wouldn't know off the top of my head. @stephentoub or @weshaggard may have a better idea.

[eerhardt]

Or maybe use a #if and just do the current code for .Net Native, but use FileVersionInfo APIs for everything else.

[weshaggard]

I know that I might have said to do this and it is better then before I do have to agree with @eerhardt that it isn't all that helpful because it will always be 4.0.0.0. At this point however I also agree with @Priya91 that I don't know if any good way to get a better version, in the context of .NET Native at least because reflection isn't going to work.

@ericstj any other options?

[eerhardt]

How about a C# code file that is generated by the build with something like:

const string BuildNumber = "< generated Build Number >";

And that's what gets used for this value on .Net Native.

When on official builds < generated Build Number > gets replaced with the official build number. When on any other build we put a "sentinel" value like 0.1 or 0.99 etc to mean it is a private/non-official build. (Or use whatever we use for privately built package numbers now).

[ericstj]

@weshaggard we can enable file version info using the UNIX impl on .netnative, though it still feels a bit heavy.

That still wouldn't be correct on .net native since the file with object in it would be the app. Maybe NETNative just transforms the IL to burn in the number.

Burning in a number during the build of this assembly would work some of the time. It's at least a min version, but if someone upgraded just this package they'd get a newer version.