GetLatestWinSDK assumes registry key will point to 32bit node for win10 sdk

[UnityAlex]

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?

[AaronRobinsonMSFT]

@UnityAlex This is a mistake on my end. This needs to be updated for VS2022 I believe. I will look into this shortly.

[UnityAlex]

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]

FWIW I'm using the VS19 installer to bolt on the win10 sdk module.

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]

So to be specific I am running build.cmd -subset libs.tests -test -c Release in our fork of the dotnet/runtime repo. It's choking on the NativeExports.csproj:

C:\Users\<username>\.nuget\packages\dnne\1.0.26\build\DNNE.targets(121,5): error MSB4018: The "CreateCompileCommand" task failed unexpectedly. [C:\<path to>\runtime\src\libraries\System.Runtime.InteropServices\tests\TestAssets\NativeExports\NativeExports.csproj]

[AaronRobinsonMSFT]

@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]

have GetLatestWinSDK check the WOW6432Node

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]

@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]

Awesome! Thank you. I really appreciate the quick response & turnaround on this issue.

[UnityAlex]

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-public repo? the dotnet/runtime sources 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.json

[AaronRobinsonMSFT]

@UnityAlex Ugh! Sorry. I need to request that get added to our NuGet feed.

[UnityAlex]

Haha no problem I figured that may be the case. Let me know when I can try again. :-)

[AaronRobinsonMSFT]

@UnityAlex Should be updated now.