Get .NET Core DLL version on Linux
I have a .NET Core app which sets metadata properties during build, using standard options in the .csproj:
On Windows, this is easy enough to retrieve from the compiled .dll either in Explorer, or via a PowerShell script. How can I do something similar on Linux? Ideally, I’d like to be able run a simple command like dotnet inspect my.dll and get a summary of metadata for that assembly, but what’s the next best thing?
2 Answers 2
$ exiftool /usr/lib64/dotnet/sdk/2.0.3/Microsoft/Microsoft.NET.Build.Extensions/tools/netcoreapp1.0/System.Threading.dll | grep -i version ExifTool Version Number : 10.55 Linker Version : 48.0 OS Version : 4.0 Image Version : 0.0 Subsystem Version : 4.0 File Version Number : 4.6.24705.1 Product Version Number : 0.0.0.0 File Version : 4.6.24705.01 Product Version : 4.6.24705.01. Commit Hash: 4d1af962ca0fede10beb01d197367c2f90e92c97 Assembly Version : 4.0.12.0
Originally discovered from here.
Watch out, though. It doesn’t work on crossgen ed stuff:
$ exiftool /usr/lib64/dotnet/sdk/2.0.3/Roslyn/Microsoft.CodeAnalysis.dll ExifTool Version Number : 10.55 File Name : Microsoft.CodeAnalysis.dll Directory : /usr/lib64/dotnet/sdk/2.0.3/Roslyn File Size : 4.6 MB File Modification Date/Time : 2018:01:24 13:12:48-05:00 File Access Date/Time : 2018:02:01 12:37:59-05:00 File Inode Change Date/Time : 2018:01:26 09:52:23-05:00 File Permissions : rw-r--r-- Error : File format error
How to get the AssemblyVersion of a .Net file in Linux
Is there any way to obtain the AssemblyVersion of a .Net executable in Linux without using mono? What I am trying to have is a script or command that will let me obtain the AssemblyVersion on Linux boxes. I tried:
#strings file.exe | grep AssemblyVersion
6 Answers 6
Try to match version numbers that span a whole line:
$ strings file.exe | egrep '^3+\.4+\.9+\.7+$'
In my (few) tests, the AssemblyVersion of the binary was always the last result.
I tested it but none of the numbers I am getting are the AssemblyVersion. In fact, I don’t see the AssemblyVerson anywhere in the strings output.
As recommended by Jb Evain you can use the Mono Disassembler.
monodis --assembly file.exe | grep Version
For compatibility with a wider sample of assemblies, use ikdasm -assembly (also distributed with Mono) instead of monodis —assembly .
The ikdasm tool that is also distributed with Mono is more robust than monodis , which unfortunately crashes with the message «Segmentation fault: 11» on many DLL files. The maintainers explicitly recommend the use of ikdasm rather than monodis : https://github.com/mono/mono/issues/8900#issuecomment-428392112
Usage example (with an assembly that monodis currently cannot handle):
ikdasm -assembly System.Runtime.InteropServices.RuntimeInformation.dll | grep Version:
Another option is to use exiftool , as in:
$ exiftool -AssemblyVersion -ProductVersion ./System.Private.CoreLib.dll Assembly Version : 7.0.0.0 Product Version : 7.0.4+0a396acafe9a7d46bce11f4338dbb3dd0d99b1b4
It’s absurd and ridiculous but exiftool can actually read the dotnet assembly info! It reads other properties as well. And exiftool ./System.Private.CoreLib.dll is much simpler than using monodis. Not to speak of microsofts own dotnet-ildasm. Cudos @vulcan-raven and to dthe devs of exiftool.
This is a really old question and just about everything has changed, but as of dotnet 2.1 (so you can dotnet tool install ) you can install dotnet-ildasm :
dotnet tool install --tool-path . dotnet-ildasm
Then you can use this function:
function dll_version < local dll="$1" local version_line local version version_line="$(./dotnet-ildasm "$dll" | grep AssemblyFileVersionAttribute)" # Uses SerString format: # 01 00 is Prolog # SZARRAY for NumElem # version chars for Elem # 00 00 for NamedArgs # See: # https://www.ecma-international.org/publications/files/ECMA-ST/ECMA-335.pdf#%5B%7B%22num%22%3A2917%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C87%2C321%2C0%5D [[ $version_line =~ \(\ 01\ 00\ [0123456789aAbBcCdDeEfF][0123456789aAbBcCdDeEfF]\ (.*)\ 00\ 00\ \)$ ]] dotcount=0 for i in $; do if [[ $i =~ ^2[eE]$ ]]; then (( dotcount++ )) fi if (( dotcount == 3 )); then break fi echo -n -e "\u$i" done >
Viewing Linux Library / Executable version info
The version info in not explicitly stored in an ELF file. What you have in there is the name of the library, the soname , which includes the major version. The full version is usually stored as a part of the library file name.
If you have library, say libtest.so , then you usually have:
- libtest.so.1.0.1 — The library file itself, containing the full version
- libtest.so.1 — Symlink to libtest.so.1.0.1 , having the same name as soname
- libtest.so — Symlink to libtest.so.1 used for linking.
In the library file libtest.so.1.0.1 , there will be an entry called SONAME in dynamic section, that will say this library is called libtest.so.1 . When you link a program against this library, the linked program will store the soname of the library under NEEDED entry in the dynamic section.
If you want to verify, what exactly is in which ELF file, you can try to run:
where elffile can be either an library of an executable.
If you simply want to get the library version, you can play with:
readelf -d /path/to/library.so |grep SONAME
AFAIK, there’s no such info (at least not by default) in executable files.
Or you can rely on the program itself or your packaging system, as Rahul Patil wrote.
nice info, it’s new to me never used readelf, if you don’t mind , may i ask you where & why use readelf
Readelf (and similar tools) is useful, when you want to look inside an elf file :). I use it mostly when programming to look up symbols in libraries (when something doesn’t work), or when there’s some problem with a library. (man readelf)
You can use ldconfig -v | grep libraryname , also command has option command -V or binaryfile —version
test@ubuntukrb12:~# ls --version ls (GNU coreutils) 8.13 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later . This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.
also you can use yum or aptitude based on distro you are using eg.
in RHEL5/CENTOS5/Fedora you can use yum info packagename or if it installed then use rpm —version packagename
[root@ldap1 ~]# yum info bind97 Loaded plugins: downloadonly, fastestmirror, security Loading mirror speeds from cached hostfile * base: mirrors.sin3.sg.voxel.net * epel: mirror.imt-systems.com * extras: mirrors.sin3.sg.voxel.net * updates: mirrors.sin3.sg.voxel.net Installed Packages Name : bind97 Arch : i386 Epoch : 32 Version : 9.7.0 Release : 10.P2.el5_8.4 Size : 6.3 M Repo : installed Summary : The Berkeley Internet Name Domain (BIND) DNS (Domain Name System) server URL : http://www.isc.org/products/BIND/ License : ISC Description: BIND (Berkeley Internet Name Domain) is an implementation of the DNS : (Domain Name System) protocols. BIND includes a DNS server (named), : which resolves host names to IP addresses; a resolver library : (routines for applications to use when interfacing with DNS); and : tools for verifying that the DNS server is operating properly.
In Ubuntu You can use aptitude show pkgname or dpkg —version pkgname
root@ubuntukrb12:~# aptitude show bind9utils Package: bind9utils State: installed Automatically installed: yes Version: 1:9.8.1.dfsg.P1-4ubuntu0.4 Priority: optional Section: net Maintainer: Ubuntu Developers Architecture: amd64 Uncompressed Size: 306 k Depends: libbind9-80, libc6 (>= 2.14), libdns81, libisc83, libisccc80, libisccfg82 Conflicts: bind9utils Replaces: bind9 (
Get .NET Core DLL version on Linux
I have a .NET Core app which sets metadata properties during build, using standard options in the .csproj:
On Windows, this is easy enough to retrieve from the compiled .dll either in Explorer, or via a PowerShell script. How can I do something similar on Linux? Ideally, I’d like to be able run a simple command like dotnet inspect my.dll and get a summary of metadata for that assembly, but what’s the next best thing?
Solution – 1
$ exiftool /usr/lib64/dotnet/sdk/2.0.3/Microsoft/Microsoft.NET.Build.Extensions/tools/netcoreapp1.0/System.Threading.dll | grep -i version ExifTool Version Number : 10.55 Linker Version : 48.0 OS Version : 4.0 Image Version : 0.0 Subsystem Version : 4.0 File Version Number : 4.6.24705.1 Product Version Number : 0.0.0.0 File Version : 4.6.24705.01 Product Version : 4.6.24705.01. Commit Hash: 4d1af962ca0fede10beb01d197367c2f90e92c97 Assembly Version : 4.0.12.0
Originally discovered from here.
Watch out, though. It doesn’t work on crossgen ed stuff:
$ exiftool /usr/lib64/dotnet/sdk/2.0.3/Roslyn/Microsoft.CodeAnalysis.dll ExifTool Version Number : 10.55 File Name : Microsoft.CodeAnalysis.dll Directory : /usr/lib64/dotnet/sdk/2.0.3/Roslyn File Size : 4.6 MB File Modification Date/Time : 2018:01:24 13:12:48-05:00 File Access Date/Time : 2018:02:01 12:37:59-05:00 File Inode Change Date/Time : 2018:01:26 09:52:23-05:00 File Permissions : rw-r--r-- Error : File format error
Solution – 2
Finding the version of a program in a pod
cat /usr/lib64/dotnet/sdk/2.0.3/Microsoft/Microsoft.NET.Build.Extensions/tools/netcoreapp1.0/System.Threading.deps.json | grep System.Threading
If the deps.json file is availible just FYI