-
Notifications
You must be signed in to change notification settings - Fork 10.4k
Fix StartupTests.StartsWithDotnetInstallLocation #6589
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
WOW6432Node doesn't exist on 32bit windows and for 32bit apps AFAIK. You might need to make it conditional on running inside 64bit process Remove flag parameter from TryGetString |
Another option could be to open the HKEY_LOCAL_MACHINE section using RegOpenKeyEx with the KEY_WOW64_32KEY flag which seems defined all the way back to Windows XP on both the 32-bit and 64-bit versions. Since it's a predefined registry key, there's no need to close it. Then you could use the newly opened section/key in place of HKEY_LOCAL_MACHINE when you call TryGetString without any need to include WOW6432Node in the subsection name since the KEY_WOW64_32KEY flag should do that implicitly for you that on 64-bit systems. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs to work on 32 bit windows
🆙 📅 |
I'm still going to play around with calling RegOpenKeyEx to get an HKEY that already contains WOW6432Node. Would be a bit cleaner than this. |
I think this looks good enough. |
Discussed offline with @pakrym, we are going to stick with this rather than calling RegOpenKeyEx as they are functionally the same. |
The reg key flag RRF_SUBKEY_WOW6432KEY doesn't evaluate to WOW6432Node on Win8 and below. Therefore we need to insert it ourselves.
StartsWithDotnetInstallLocation is failing on CI currently.