Hostfxr Installation Location Path Key May Diverge from Specification

[nagilson]

Description

sharedhost has Path but InstallLocation does not, and does not exist

My understanding based on this spec is that the registry should contain a path key to the dotnet host. I looked at my registry to see if that was valid. I was able to find a Path key under a location very similar to what the spec stated, but it was in sharedhost, which seems to be inconsistent with the design decision determined in https://github.com/dotnet/designs/blob/main/accepted/2021/install-location-per-architecture.md#:~:text=On%20Windows%20the,arch%3E%5CInstallLocation, where InstallLocation is mentioned as the place in which the install location is stored.

On Windows the multi-arch situation already exists with x86 and x64 architectures. Each installs into a different location and is registered accordingly. The registration mechanism in registry includes the architecture, the key path is HKLM\SOFTWARE\dotnet\Setup\InstalledVersions<arch>\InstallLocation.

On my machine, this is stored in sharedhost, not InstallLocation. My machine is Win 11 and x64.

runtime/src/installer/pkg/sfx/installers/dotnet-host.proj

Line 11 in e33be4d

<RegKeyProductName>sharedhost</RegKeyProductName>

That seems to be what the code does as well. I didn't see any reference to InstallLocation as mentioned in the doc. I also didnt see a new doc describing this sharedhost behavior. Is that expected? Or, Is this design / spec wrong and needs to be updated? Or am I confused and this Path key is for something else, and there never was a place where the path to .NET is marked in the registry?

WoW Node Missing Path Key

There is also information that can be put in the Wow Node. For this information, it doesn't appear to have a Path key? Is that expected?

Registry Inconsistency with --info

Here's another interesting observation. My 9.0.0-preview.7.24405.7 host running dotnet --info says there is an x86 dotnet registered at InstallLocation, but that doesn't exist on my registry. It's got a sharedhost key, though. The registry above shows hostfxr under the InstalledVersions node and some other installation information which is good, but none of those seem to store the path. Is InstalledVersions a placeholder text, then, and substitutable for hostfxr, sharedhost, etc?

cc @elinor-fung @richlander

Reproduction Steps

Install .NET 9 or .NET 8 preview host on various machines and observe regedit behavior can be different. Install the .NET 9 host and see sharedhost is used instead of InstallLocation.

Expected behavior

Should it not be in InstallLocation?

Actual behavior

See above.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

[elinor-fung]

The InstallLocation value is always written to the 32-bit registry:

runtime/src/installer/pkg/sfx/installers/host.wxs

Lines 35 to 39 in e33be4d

	<Component Id="cmpInstallLocation" Directory="TARGETDIR" Guid="*" Win64="no">
	<RegistryKey Root="HKLM" Key="SOFTWARE\dotnet\Setup\InstalledVersions\$(var.Platform)">
	<RegistryValue Action="write" Name="InstallLocation" Type="string" Value="[DOTNETHOME]" KeyPath="yes"/>
	</RegistryKey>
	</Component>

That is what the host uses when determining registered installs. It does not look under the 64-bit hive or at ...\sharedhost\Path.

Or, Is this design / spec wrong and needs to be updated?

Added a clarification to the design doc: dotnet/designs#325

WoW Node Missing Path Key

Looking at the setup authoring, the sharedhost\Path key is used to add to the PATH environment variable. It is only added for the native machine architecture, so will not exist in the WoW node / 32-bit hive on a 64-bit machine.

runtime/src/installer/pkg/sfx/installers/host.wxs

Lines 41 to 55 in e33be4d

	<Component Id="cmdPath" Directory="DOTNETHOME" Guid="*">
	<?if $(var.Platform)~=x64 ?>
	<!-- For x64 installer, only add to PATH when actually on native architecture -->
	<Condition>NOT NON_NATIVE_ARCHITECTURE</Condition>
	<?elseif $(var.Platform)~=x86 ?>
	<!-- For x86 installer, only add to PATH when not on 64-bit platform -->
	<Condition>NOT VersionNT64</Condition>
	<?endif?>
	<!-- A stable keypath with the right SxS characteristics for our PATH entry-->
	<RegistryKey Root="HKLM" Key="SOFTWARE\dotnet\Setup\InstalledVersions\$(var.Platform)\sharedhost">
	<RegistryValue KeyPath="yes" Action="write" Name="Path" Type="string" Value="[DOTNETHOME]"/>
	</RegistryKey>
	<Environment Id="E_PATH" Name="PATH" Value="[DOTNETHOME]" Part="last" Action="set" System="yes" />
	</Component>

dotnet --info says there is an x86 dotnet registered at InstallLocation, but that doesn't exist on my registry

Can you check the 32-bit view?

[nagilson]

Can you check the 32-bit view?

Aha, thank you -- they are under the node here!

I assume it's also under the 32-bit view on arm64, but I'll verify that with a VM.

Looking at the setup authoring, the sharedhost\Path key is used to add to the PATH environment variable. It is only added for the native machine architecture, so will not exist in the WoW node / 32-bit hive on a 64-bit machine.

Awesome, that's super helpful to know as well. My understanding, then, is that InstallLocation stores all of the possible installs, and the sharedhost\Path key is used for PATH lookup / should theoretically be the default host when calling dotnet on the terminal.

Knowing that will always be in that location is great.

This was super helpful. Thank you. I think updating the doc is good, so I'll add that tag to this issue.