Open Varorbc opened 2 years ago
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
Tagging subscribers to this area: @vitek-karas, @agocke, @vsadov See info in area-owners.md if you want to be subscribed.
Author: | Varorbc |
---|---|
Assignees: | - |
Labels: | `area-Host`, `untriaged` |
Milestone: | - |
Side note about the screenshot from registry. The install locations are actually only used from the 32-bit view of the registry. So on x64 OS you need to look at Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions
.
@joeloff - this is done by the installer, did we try to fix this so that the installer doesn't write non-sensical info about other architectures? For example on my machine it shows the arm64 to be installed in x86 directory:
arm64 [C:\Program Files (x86)\dotnet]
registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\arm64\InstallLocation]
Overall this is just confusing - there's definitely non arm64 runtime available on the machine and trying to run arm64 app will fail. But I agree that dotnet --info
looks confusing (and in this case it's that there's actually sort of wrong info in the registry).
@elinor-fung should we maybe change what dotnet --info
prints out as the location of the registry key? Since now if I run x64 dotnet
it prints out registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\arm64\InstallLocation]
which is technically wrong, since it's actually in registered at [HKLM\SOFTWARE\WOW6432Node\dotnet\Setup\InstalledVersions\arm64\InstallLocation]
@vitek-karas the path entry is definitely wrong.
@joeloff do you want to move the bug to the right place then? Since it's really a setup issue, we should not be writing the path there.
Yeah, move it to installer for now. I suspect though that this is coming from Arcade since there's some built-in templates/tasks that the runtime uses for generating its installers, but at least this way we'll track it and once we've triaged/assigned we can move it to Arcade if necessary.
@vitek-karas @joeloff https://github.com/dotnet/runtime/pull/70403
@Varorbc yes - that's what added that section to dotnet --info
, but it's reading the info from registry, which is wrong in this case.
Old issue triage: We can't reproduce this currently so closing. Ping if you still can.
@marcpopMSFT I still reproduced using the 9.0 sdk
@marcpopMSFT ping.please reopen
Do you have any other SDKs installed as well? A few of us have tried this and don't see arm64 listed. I wonder if something is leftover in your registry from some prior state.
This is a list of SDKS I have installed. What registry information do I need to provide and if so, please let me know.
Is this an arm64 machine with an x64 install?
Description
Why is the arm64 sdk found on x64 machines?
Reproduction Steps
dotnet --info
Expected behavior
arm64 should not be found
Actual behavior
Regression?
No response
Known Workarounds
No response
Configuration
No response
Other information
No response