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

MSBuild chooses the wrong DirectX SDK version #8

Closed
smx-smx opened this Issue Oct 27, 2017 · 7 comments

Comments

Projects
None yet
2 participants
@smx-smx
Copy link

smx-smx commented Oct 27, 2017

I'm trying to build the DataViewer on Windows 10 and Visual Studio 2017, but it seems MSBuild picks the first SDK version it can find, in my case Windows 8.1 SDK, thus breaking the build.
When running the build process with MSBuild set to verbose, this is what happens:

5> C:\Program Files (x86)\Windows Kits\8.1\bin\x86\Fxc.exe /nologo /Emain /T vs_5_1 /Fo obj\Debug\Shaders\ParticleVS.cso Shaders\ParticleVS.hlsl
5> Unsupported shader model specified "vs_5_1"

I tried to look for a solution but it seems that Visual Studio, unlike with C++ projects, doesn't let us target a specific SDK version while using C#. I tried manually setting <TargetPlatformVersion> in the project file but it seems to be ignored.

@tgjones

This comment has been minimized.

Copy link
Collaborator

tgjones commented Oct 27, 2017

The tool I'm using to compile shaders during the build is supposed to pick the most up-to-date Windows SDK that you have installed on your computer. Apart from the Windows 8.1 SDK, do you have any other Windows SDKs installed?

Also, can you tell me which versions you have listed in your registry under this key:

HKLM\Software\Microsoft\Windows Kits\Installed Roots
@tgjones

This comment has been minimized.

Copy link
Collaborator

tgjones commented Oct 27, 2017

This was also asked on Stack Overflow here, by @paavohuhtala.

@tgjones

This comment has been minimized.

Copy link
Collaborator

tgjones commented Oct 27, 2017

If you look at this file, you'll see the logic to find the path to fxc.exe. Specifically, the GenerateFullPathToTool() and GetWindowsKitRoots() methods.

C:\Users\[username]\.nuget\packages\microsoft.hlsl.csharpvb\1.0.1\build\FxCompile.cs
@smx-smx

This comment has been minimized.

Copy link

smx-smx commented Oct 28, 2017

The problem with that file, FxCompile.cs, seems to be that it gets the first available SDK version it can find:

    foreach (string kitRoot in GetWindowsKitRoots())
            {
                DirectoryInfo directoryInfo = new DirectoryInfo(kitRoot);
                FileInfo[] files = directoryInfo.GetFiles(kFileName, SearchOption.AllDirectories);
                if (files != null && files.Length > 0)
                {
                    // Just take the first directory we find.
                    fullPath = Path.GetDirectoryName(files[0].FullName);
                    break;
                }
            }

Inside HKLM\Software\Microsoft\Windows Kits\Installed Roots i have some GUIDs, KitsRoot81, and KitsRoot10

@smx-smx

This comment has been minimized.

Copy link

smx-smx commented Oct 28, 2017

Alright, so the issue is in the GenerateFullPathToTool function.
It expects Fxc.exe to be in <basedir>\bin\x86\fxc.exe. That works with Windows 8.1, but with Windows 10 the path is <basedir>\bin\<build>\x86, for instance:

C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x86
After placing some debug prints in FxCompile.cs, this is what i got:

Check Path C:\Program Files (x86)\Windows Kits\8.1\bin\x86\Fxc.exe
Major: 6, Minor: 3, Build: 9600, Private: 16384
Check Path C:\Program Files (x86)\Windows Kits\10\bin\x86\Fxc.exe

Since the last path is wrong (lacking the build version), it will fallback to using the Windows 8.1 variant.

@tgjones

This comment has been minimized.

Copy link
Collaborator

tgjones commented Oct 28, 2017

Thanks for researching that. I've sent a message to the owners of the Microsoft.HLSL.CSharpVB package. Hopefully they'll be able to release a fixed version of the NuGet package. Otherwise I might pull that code in locally, but it's not actually open source so I'm not sure if I can.

@tgjones

This comment has been minimized.

Copy link
Collaborator

tgjones commented Dec 9, 2017

This should be fixed by 212aafb. I'm now using a custom MSBuild target to compile the shaders, and as part of that, I've improved the logic for finding fxc.exe in recent Windows SDKs.

@tgjones tgjones closed this Dec 9, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment