Add version.txt file to CoreCLR packages

[cesarblum]

CoreFX packages contain a version.txt with the commit the package was built from. This is really useful to determine if a given change was included in the package.

CoreCLR packages don't have that file, making it hard to determine if a change made it to a recent build. Would be nice to have it there too.

[weshaggard]

@chcosta is this something we just haven't enabled in coreclr yet?

[chcosta]

There will need to be some slight refactoring to make this work for CoreFx and CoreClr. Currently, the code path is based on execution of a "BuildAllProjects" target.

https://github.com/dotnet/buildtools/blob/a3c0637b9ae8d322078aff64fae97ee2dbcfecab/src/Microsoft.DotNet.Build.Tasks/PackageFiles/versioning.targets#L218

This should be refactored in some other way so that it is guaranteed to run because the BuildAllProjects target isn't ubiquitous across repos (even across BuildTools-enabled repos). Once it is running, there also needs to be an update to the coreclr packaging to include the version.txt file; though really, we should move that step out of corefx and coreclr and try to include it in BuildTools packaging targets as well.

[halter73]

FWIW, I found that coreclr.dll has the commit SHA in its "Product version". I don't know if libcoreclr.so also has the SHA embedded somehow.

[janvorli]

The libcoreclr.so has the version and hash embedded in it, so there is no need to add the version.txt. You can get it this way:
strings libcoreclr.so | grep "@(#)"

[chcosta]

Thanks @janvorli . CoreFx does a similar thing and bakes in commit hash information into it's dll's (managed dll's for sure, i'd have to look to see if it's happening in native binaries as well). I think there's value in having a consistent way to find this information, so that you don't have to remember to check the embedded information or a txt file. Whether that consistent way is binary embedding, a plain text file, or both; I have no preference, I just think we should try to be consistent.

[danmoseley]

@gkhanna79 @chcosta is anyone taking this on for 2.0? if not we should move it out.

[danmoseley]

MOving it out.

[ghost]

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of the experimental issue cleanup initiative we are currently trialing. Please share any feedback you might have in the linked issue.

[ghost]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.