Get version info of compiled/published dotnet application through bash

Question

I'm developing an ASP.Net Core project, where the .csproj file looks like this:

<PropertyGroup>
  <OutputType>Exe</OutputType>
  <TargetFramework>netcoreapp2.0</TargetFramework>
    <PreserveCompilationContext>true</PreserveCompilationContext>
    <AssemblyName>dummyapp</AssemblyName>
        <Version>17.12.1</Version>
    <RuntimeIdentifiers>centos.7-x64;win7-x64</RuntimeIdentifiers>
</PropertyGroup>

When this app is published for Windows, I can get the version info from its properties. Which shows 17.12.1 as mentioned.

Alternatively I can run wmic datafile where name="filepath/app.exe" get Version /value and get the same version using command prompt.

---

But is there a standard way to get the same in linux distro?

I've looked into:

• how-to-find-version-of-a-file-or-program

• Experimented with this answer. Though it is for file-system!

• Tried myapp --version and /fullpath/myapp --version as mentioned in this post. Also tried solutions with the marked duplicates.

After all the trials, it seems, I need to implement something else in the .csproj file so as to get the version info using bash. Can someone point out what needs to be done, or give a hint about the same.

---

Main method:

public static void Main(string[] args)
{
    var root = new Root();
    var config = new ConfigurationBuilder()
                     .SetBasePath(Directory.GetCurrentDirectory())
                     .AddJsonFile(SettingsFilename, optional: false,
                                  reloadOnChange: true)
                     .AddEnvironmentVariables()
                     .Build();

    config.Bind(root);

    //some codes

    var host = new WebHostBuilder()
                    .UseKestrel()
                    .UseUrls(root.AppUrl)
                    .UseConfiguration(config)
                    .UseContentRoot(Directory.GetCurrentDirectory())
                    .UseIISIntegration()
                    .ConfigureServices(s =>
                                     s.AddRouting().DetectTokenChange(config))
                    .UseSetting(WebHostDefaults.ApplicationKey, "dummyapp")
                    .Configure(app => app.UseRouter(r => r.MapPost("dumptoqueue", 
                                      async (context) => 
                                      await Task.Run(() => AddtoQueue(context)))))
                    .Build();
     host.Run();
}

App built using the command line:

dotnet publish -c release -r centos.7-x64

Answer 1

It might just be easier to use exiftool, if all you need to do via bash is to find the version of a dll file.

$ exiftool Foo.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             : 17.12.1.0
Product Version Number          : 17.12.1.0
File Version                    : 17.12.1.0
Product Version                 : 17.12.1
Assembly Version                : 17.12.1.0

Or even just:

$ exiftool -"ProductVersion" Foo.dll 
Product Version                 : 17.12.1

Answer 2

First, let's assume your Linux program is compiled into yourprog executable and that you are building it from its source code (so you can slightly change both the source code and the building procedure). It does not matter what is your build procedure, or in what programming language you are coding it. That yourprog file is probably some ELF executable or something else (e.g. a script) understandable by the execve(2) system call. Use file(1), e.g. as file yourprog, to find out what its file format. See also binfmt_misc and read about #! (shebang). Notice that every application program is started with some execve (generally done by your Unix shell, but perhaps by something else, for example systemd).

You could use strings(1) on that executable using strings ./yourprog; you'll then get most of the multibyte strings in it. Probably some of the (many) strings contain version information (if it has been put there at compile stage).

Regarding --version, it should be a convention followed by your program. See this answer. So you should improve your source code so that your program handle both --version and --help program arguments. There is no magic involved, you have to code that (perhaps your build automation could generate some C# code containing version string; how that should be done is a different question, and depend upon the particular build utility that you use; with make or ninja you'll just add some specific rules, e.g. in your Makefile or your build.ninja). So you need to understand and improve your build procedure. If you code in C#, you need to handle that from your Main, so you need to improve your Main to parse args and handle appropriately --help and --version (on Windows, it could be something else). BTW, IMHO even on other OSes it is helpful to be able to pass some program argument to query the version and to get help (I don't know Windows, but perhaps it might be /version and /help instead of --version and --help).

Notice that software versioning is always a human convention (even if using some version control system, e.g. git, is helpful). So getting that version cannot be "standard", even if it is very easy (it could also depend upon your project's conventions and coding habits, and perhaps your version control system). I guess that you could generate in your build some _timestamp_version.cs generated C# file and compile it appropriately and have that _timestamp_version.cs define some constant strings to be shown from your Main. In C with make that is a really easy trick and you just need to adapt it to your programming language and your build procedure (see also this Makefile and its _timestamp.c for a more elaborate thing related to git); in the Unix philosophy it is very common to do that, and I am surprised that you are asking that!

Maybe there is some API to query some version metadata in C# (probably related to reflection), but that is a very different question. And you just should conventionally code to display some version related string with --version....

Remember that (even on Windows, and certainly on POSIX & Linux) compilers are practically not the same as IDEs. An IDE -even on Windows- is just a source code editor capable of running external programs (e.g. compilers, debuggers, build automation tools ...). You can (and you often should) run a compiler outside of an IDE, on the command line. So you can do basic metaprogramming by generating some C# code (e.g. generating a file defining a few string constants related to version, etc). Read about the Unix philosophy (which IMHO is somehow even used inside Microsoft).

Remember that .csproj files are not, IIRC, part of the C# specification (a technical report written in English). See also this.