aspnetcoretools.so: use source control version string format.

[tmds]

.so files in the SDK use this pattern for the version string:

$ strings shared/Microsoft.NETCore.App/11.0.0-preview.7.26356.111/libSystem.Net.Security.Native.so | grep '@(#)'
@(#)Version 11.0.26.35711 @Commit: ccf0d067ca5d747484d7e330ca6aa8c14ede9cb3

aspnetcoretools.so doesn't include such a string:

$ strings /home/tmds/projects/tools-dont-execute/dotnet/sdk/11.0.100-preview.7.26356.111/DotnetTools/aspnetcoretools/11.0.0-preview.7.26356.111/tools/any/fedora.44-x64/libaspnetcoretools.so | grep '@(#)'

It would be nice if it would.

Note: the hash is appearing in some places in the binary already:

$ strings sdk/11.0.100-preview.7.26356.111/DotnetTools/aspnetcoretools/11.0.0-preview.7.26356.111/tools/any/fedora.44-x64/libaspnetcoretools.so | grep ccf0d067ca5d747484d7e330ca6aa8c14ede9cb3
11.0.0-preview.7.26356.111+ccf0d067ca5d747484d7e330ca6aa8c14ede9cb3
CommitHashPccf0d067ca5d747484d7e330ca6aa8c14ede9cb3
https://github.com/dotnet/dotnet/tree/ccf0d067ca5d747484d7e330ca6aa8c14ede9cb3,OriginalRepoCommitHashP2b7a3d5c1757296f038696e208662370edac5368
.NET: ilc 11.0.0-preview.7.26356.111+ccf0d067ca5d747484d7e330ca6aa8c14ede9cb3

[tmds]

cc @omajid

[tmds]

@mthalman @MichalStrehovsky @am11 ptal.

[am11]

These are NativeAOT tools. The decision was objectwriter will write a string in .comment section and we will use readelf:

# binutils' readelf
$ readelf readelf -p .comment libaspnetcoretools.so

String dump of section '.comment':
  [     0]  clang version 22.1.7
  [    15]  Linker: LLD 22.1.7
  [    29]  GCC: (Alpine 12.2.1_git20220924-r4) 12.2.1 20220924
  [    5d]  .NET: ilc 11.0.0-preview.7.26326.125+63a0cc507b252c702ac2b6d53d922b6533e5add6

# or llvm-toolchain's readelf
$ llvm-readelf readelf -p .comment libaspnetcoretools.so

String dump of section '.comment':
[     0] clang version 22.1.7
[    15] Linker: LLD 22.1.7
[    29] GCC: (Alpine 12.2.1_git20220924-r4) 12.2.1 20220924
[    5d] .NET: ilc 11.0.0-preview.7.26326.125+63a0cc507b252c702ac2b6d53d922b6533e5add6

Another part of the decision was it only works on ELF platforms (.so, not .dylib or .dll), which provide a "natural" home for this.

See the discussion in dotnet/runtime#79623.

[tmds]

Yes, this string shows up when I run the strings command and grep for the hash.
I assume this one is meant to identify ilc and would also be included in apps built by the user.

My question is if we want to add the same version string format in aspnetcoretools.so like the other .so files have that come with .NET? The answer may be no if it is not straight forward/important.

[am11]

strings is formally not the right tool for reading ELF section; readelf is. SCCSID is a separate concept (not .NET-specific one) and that's where strings makes sense.

I tried to pitch this idea for all nativeaot apps as well as native apps produced for .NET product (crossgen2, ilc and cDAC) it wasn't accepted. So, it's an existing pattern product-wide since .NET 7+ (since NativeAOT onboarding).

if it is not straight forward

It is pretty straightforward to include SCCSID, all we need is to create an .o file from arcade produced version.c file which fills up this template https://github.com/dotnet/runtime/blob/f00ccfddcd92f805d2d721ccaabfad6a9089e845/eng/native/version/_version.c, put a <NativeLibrary Include="$(ArtifactsObjDir)_version.o" /> in tools projects and it will show up. So it isn't a technically challenging problem but a product team's decision.

[tmds]

but a product team's decision

Exactly, this is my question.