Programmatically way to detect installed .NET Core version

[Symbai]

Is there any reliable way to programmatically detect if .NET Core is installed on a computer (Windows only) and get the installed version? I'm aware of most guides say we can run dotnet --version or even worser dotnet --info in command line. However this is more related for a human sitting in front of a computer and wants to see the version and for this purpose only its okay. But it's not a good way to get the version programmatically. We would have to run cmd silently and then parse string ourselves and the string output might change in the future. Also if dotnet core isn't installed at all, the command fails completely.

For determining .NET Framework there is a reliable way via registry https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/how-to-determine-which-versions-are-installed where we don't have to run any hidden windows and we don't have to parse text. Can we have something like this for .NET Core too please?

[vitek-karas]

Currently running 'dotnet --version' or 'dotnet --info' is probably the simplest way. You can also programmatically look up the dotnet folder in Program Files. If it's there, go to the host/fxr sub directory and find the latest version there. In it there's hostfxr.dll. This library exposes an export hostfxr_get_available_sdks. You can load the library and call this API (no setup necessary) to get the list of installed SDKs - this is similar to dotnet --info (it will list the same set of SDKs as dotnet --info does).

In .NET Core 3 we're working on so called "globally registered location" which will add a registry key which would point to the "global location" (instead of relying on knowing about Program Files). I don't think it will contain the latest version installed though. See dotnet/cli#10100 for more details.

@johnbeisner would know more.

[Symbai]

Thanks @vitek-karas the registry key will be useful. I still recommend to add a key for the version though its much easier to read this information from a static location for all kind of software and programming languages including and most important installers like inno setup. I don't think you can easily load the library with inno setup and call the API so it still requires workarounds

[vitek-karas]

@Symbai can you please describe in a bit more detail your scenario specifically what you need the version number for, and what exact version number you're looking for (highest SDK version, highest "runtime" version, something else, ...)? Feel free to add more details to the discussion in dotnet/cli#10100.

[steveharter]

See also https://github.com/dotnet/core-setup/issues/4453

[vitek-karas]

@Symbai partial solution may be part of dotnet/core-setup#5336 . The tool could include the proposed nethost and call the nethost_get_hostfxr_path which would fail if there's no .NET Core installed. There's still not API to enumerate the available installed versions of the runtime.

Please note that in theory answering "what versions of runtime are installed" is a bit tricky since the install actually puts shared frameworks onto the disk. And technically there's no guarantee that all the relevant framework will be available (for example there could be Microsoft.NETCore.App version 3.0, but no ASP.NET v3.0 available). That said, such situation should be very rare (and typically means either broken install, or somebody manually modified the install).

[Symbai]

@vitek-karas That could work, yes. Does it require to include any additional files or will it be an API native apps can call on all systems which supports .NET Core?

[vitek-karas]

The proposal is that "your" app would carry the nethost library with it. We won't introduce a system-wide library for .NET Core (that creates all kinds of servicing nightmares). The library would expose a native API (C-style).

[Symbai]

@vitek-karas Ok, when it will be small enough in size then it shouldn't be a problem.

[vitek-karas]

The new nethost should be very similar in size to apphost which is currently cca 300KB (win-x64).

That said there's an open issue on apphost size regression - #3369

[jeffschwMSFT]

cc @elinor-fung

[jeffschwMSFT]

@elinor-fung does the native hosting feature address the feedback in this issue?

[vitek-karas]

Starting with .NET Core 3.0 the installers will typically also register the runtime as described here: https://github.com/dotnet/designs/blob/master/accepted/install-locations.md
On Windows this will be true pretty much always (again except cases where somebody installed it through different means than the msi). On Linux/Mac this might not be as reliable.

Note that the nethost API described above checks all the locations and so using that should provide you with the best answer.

Depending on your scenario, if you need to detect if a particular application will be able to run, you can do that by calling the new APIs on hostfxr: https://github.com/dotnet/core-setup/blob/master/Documentation/design-docs/native-hosting.md
Calling hostfxr_initialize_for_dotnet_command_line and pointing to your app should either succeed, in which case the app should be able to run, or fail otherwise.

This approach will only work though if the machine has .NET Core 3.0 installed on it.

[vitek-karas]

Closing as the main concern seems to have a solution.

@Symbai please feel free to reopen, or open a new one if you run into issues.