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.
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