Repository navigation
GetLatestWinSDK assumes registry key will point to 32bit node for win10 sdk #96
Description
Firstly I'm not entirely sure if this is a Visual Studio installer issue or DNNE but after running the visual studio installer to add the win10 sdk to the system the KitsRoot10 registry key is pointing to C:\Program Files\Windows Kits\10\ where the sdk's files appear to actually be in the 32bit node's location of Program Files (x86). As far as I can tell it seems like the win10 sdk always winds up in Program Files (x86) so I was curious if it made sense to instead have GetLatestWinSDK check the WOW6432Node for the sdk location to ensure it always pointed to the correct location?
Activity
AaronRobinsonMSFT commentedon Nov 16, 2021
@UnityAlex This is a mistake on my end. This needs to be updated for VS2022 I believe. I will look into this shortly.
UnityAlex commentedon Nov 16, 2021
Is there a suggested work-around for this? I'm attempting to get a CI machine functioning and I'm stuck on this. FWIW I'm using the VS19 installer to bolt on the win10 sdk module.
AaronRobinsonMSFT commentedon Nov 16, 2021
Oh. Now I am confused. For the CI, what are you using to build—VS or
dotnet? If we can root cause this, I can push out a fix very fast today.UnityAlex commentedon Nov 16, 2021
So to be specific I am running
build.cmd -subset libs.tests -test -c Releasein our fork of thedotnet/runtimerepo. It's choking on the NativeExports.csproj:AaronRobinsonMSFT commentedon Nov 16, 2021
@UnityAlex Oh, then this is definitely a priority. I'm not sure why we are not seeing this in the official CI. @jkoritzinsky or @elinor-fung do you have any thoughts?
elinor-fung commentedon Nov 16, 2021
Yeah, I think it shoud be updated to do that.
I found a similar issue on developer community where they addressed it by checking WOW6432Node first:
https://developercommunity.visualstudio.com/t/ucrt-doesnt-work-in-x64-msbuild/1184283#T-N1201257
AaronRobinsonMSFT commentedon Nov 16, 2021
@UnityAlex I've published a new package - https://www.nuget.org/packages/DNNE/1.0.27.
Thanks for reporting this!
@elinor-fung Thank you for the help.
UnityAlex commentedon Nov 17, 2021
Awesome! Thank you. I really appreciate the quick response & turnaround on this issue.
UnityAlex commentedon Nov 17, 2021
Sorry to bother you one last time. Do you know if something special needs to be done for this package to wind up in the
dotnet-publicrepo? thedotnet/runtimesources nuget packages from there and this latest package doesn't appear to be available there yet. Here's a link to the json for the repo that I saw in the build error: https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public/nuget/v3/index.jsonAaronRobinsonMSFT commentedon Nov 17, 2021
@UnityAlex Ugh! Sorry. I need to request that get added to our NuGet feed.
UnityAlex commentedon Nov 17, 2021
Haha no problem I figured that may be the case. Let me know when I can try again. :-)
AaronRobinsonMSFT commentedon Nov 17, 2021
@UnityAlex Should be updated now.