runtime: InstallLocation registry key doesn't exist for .NET Core 3.1

According to https://github.com/dotnet/core-setup/issues/4904 and https://github.com/dotnet/designs/blob/master/accepted/install-locations.md I should be able to check the version of .NET Core installed from 3.0 onwards in the following registry location…

HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\<arch>\InstallLocation

However this is not the case on my machine. I only have…

HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x64\sharedhost with a Version key. No other folders or keys under HKLM\SOFTWARE\dotnet.

I realise this may be related to having Visual Studio 2019 installed on my development machine (WIndows 10 Pro) which I assume installed .NET Core SDK (3.1) rather than the runtime.

Is there a reliable way of simply detecting programmatically if .NET Core 3.1 exists for both runtime and SDK? Or has the registry key location changed since 3.0?

My requirement is to check it’s installed in an Inno Setup installer and install the runtime if missing. I can’t rely on the ‘dotnet’ command as I have no idea if it’s on the PATH and don’t want to go trawling around the filesystem to find it with potential for it to be in a non-standard location.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 1
  • Comments: 29 (14 by maintainers)

Most upvoted comments

The other error code to watch for is
FrameworkMissingFailure (0x80008096)

(That would happen if there already is .NET Core on the box, but not high enough version to run your app).

Otherwise I agree with what you wrote.

You could use the native hosting APIs to try to “Start” an app with your custom .runtimeconfig.json (which would contain the right version you depend on) - during install. That would be calling the hostfxr_initialize_for_runtime_config - see native hosting. And if that fails you can ask the user to install it. That is basically programatic way of what you suggested (an empty app which just causes the popup).

Please make sure you’re looking into 32bit registry tree - the doc specifically states:

Windows - the installer will store the install location in 32-bit registry (for both 32-bit and 64-bit installations): HKLM\SOFTWARE\dotnet\Setup\InstalledVersions<arch>\InstallLocation - where <arch> is one of the x86, x64, arm or arm64. Note that this registry key is “redirected” that means that 32-bit processes see different copy of the key then 64bit processes. So it’s important that both installers and the host access only the 32-bit view of the registry.

When looking at it using regedit on a 64bit OS the actual path is: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions

Using APIs there are flags to ask for 32bit view of the registry. The 64bit tree has the dotnet/Setup keys in it, but those will not contain the InstallLocation values.