vs2017 action results in solution that targets Windows SDK 8.1

[JohannesMP]

On windows 10 with a c++ project, using premake5 vs2017 will result in a solution that targets the Windows SDK 8.1, not the new 10.0.* SDK Versions.

Example error message when trying to build a bog standard 'Hello World' C++ solution created with Premake5 (compiled from source on commit 66362c0 ):

1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Platforms\Win32\PlatformToolsets\v141\Toolset.targets(34,5): error MSB8036: The Windows SDK version 8.1 was not found. Install the required version of Windows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution".

This will always happen on a machine that only has VS2017 installed, without the 8.1 SDK, which is the default state. On such a machine, the 'Retarget Projects' right click option shows the following:
.

While this is a quickfix, I feel that the default behavior for the vs2017 action should be to use the 10.0 SDK that is guaranteed to be installed, not the 8.1 SDK that will become less and less used as more devs upgrade to using only 2017.

We should not assume that someone running the vs2017 action has VS2015 or the older SDK installed.

---

Edit: I just saw #450 and the addition of the systemversion, so at least I have a nicer workaround now with systemversion("10.0.15063.0"), but I still feel that it would be a more reasonable default than 8.1.

[dcourtois]

I have the same problem. And even worse in my opinion is that bootstraping Premake with vs2017 doesn't work : dev /upgrade will not update the SDK version which will still point to 8.1 :/

Basically doing this will not work:

"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat"
nmake -f Bootstrap.mak windows

[JohannesMP]

If it helps, I ended up adding this to my premake5.lua file:

function os.winSdkVersion()
    local reg_arch = iif( os.is64bit(), "\\Wow6432Node\\", "\\" )
    local sdk_version = os.getWindowsRegistry( "HKLM:SOFTWARE" .. reg_arch .."Microsoft\\Microsoft SDKs\\Windows\\v10.0\\ProductVersion" )
    if sdk_version ~= nil then return sdk_version end
end

The code for which I believe I found in another issue or comment on a commit (can't find it again right now, but all credit to them)

Then in the project configuration you can just do:

filter {"system:windows", "action:vs*"}
    systemversion(os.winSdkVersion() .. ".0")

This has worked for me on different windows 8.1 and 10 machines what each have different SDK's installed

[dcourtois]

Thanks, works like a charm on my projects ! Maybe this should be the default for the vs2017 action ? Visual Studio 2017 doesn't seem to support any SDK < 10.0, so maybe the vs2017 action should initialize the systemversion from the registry like your snippet does ? (if any of the authors can share their view on this ?)

[samsinsane]

The below is just my opinion, and the others may disagree with me.

Visual Studio 2017 doesn't seem to support any SDK < 10.0

The installer provides the option to install the 8.1 SDK. So it does support it, just not as part of the "default" installation, but it is there, and others might choose to install it.

so maybe the vs2017 action should initialize the systemversion from the registry like your snippet does ?

This won't work when generating the project files on another machine, this is something that @starkos feels very strongly about. Additionally, IIRC this registry key is actually the last SDK installed, not the latest SDK available. There's only one version, yet I have two versions installed on my desktop and three installed on my tablet - where do you get the oldest SDK installed?

• Is there a version of the 10.0 SDK that is guaranteed to be installed? I don't think so, since my desktop has 10.0.15063.0 and 10.0.16299.0 but my tablet only has 10.0.10150.0, 10.0.10240.0 and 10.0.10586.0.
• Will a future update to VS2017 change the default SDK version and will people open issues because Premake is doing the wrong thing again?
• What about VS2015? It also supports specifying the SDK version. It would be inconsistent to only have VS2017 pick a random SDK.
• Defaulting to the latest version installed can cause issues if functions are added/removed between the versions. (I have no idea if there's any API differences)
• This particular API doesn't support defaulting to what the tool uses. We would need to add a way to do this in the event you don't want the element to be emit. For example, when you're using the versions of VS2015 prior to Update 3.
• What about those users that opt to not install the Windows 10 SDK with VS2017? The registry key is only for the Windows 10 SDK, so likely wouldn't exist.

Having said all of this, I find it quite infuriating that I can't bootstrap Premake with VS2017 - nor can I build most of my projects without modifying the build scripts after reinstalling my OS and only installing VS2017 with the Win10 SDK. All because Microsoft decided to have VS2017 default to the 8.1 SDK even when it's not installed. 😡

[dcourtois]

The installer provides the option to install the 8.1 SDK. So it does support it, just not as part of the "default" installation, but it is there, and others might choose to install it.

Yes, you can install 8.1, but as far as I've tested, if you actually try to build a simple app using Visual Studio 2017 with the v140 platform toolset (the default) and 8.1 Windows SDK, it won't compile with the following errors:

c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.11.25503\include\cstddef(5): fatal error C1083: Cannot open include file: 'stddef.h': No such file or directory

Basically, platform toolset 140 is not compatible with Windows SDK 8.1 (and probably anything lower) so it doesn't make any sense to use the v140 platform toolset with any SDK other than 10 : it won't build.

Edit : I read your comment too quickly, so I removed what I previously wrote after that. And I can only update what I think :

Since v140 + sdk8.1 and lower is not buildable, why not, just in this case and if the user script didn't specifically called systemversion or toolset, try to get the latest locally installed SDK version 10, and if found, use it ? The default project would not build anyway, no matter the machine it's built on !

And that would solve the problem of Premake not bootstrapping with vs2017 :)

I hope I'm making sense (english is not my native language, so expressing ideas clearly to others can be a bit difficult sometimes :p)

[starkos]

Is there a sensible default value we can use, rather than looking the value up in the registry?

I don't mind looking up the value where it is possible, but there needs to be a solution for people generating projects from Linux and macOS too.

[tvandijck]

Maybe I'm missing something, but

nmake -f Bootstrap.mak MSDEV=vs2017 windows-msbuild

Works perfectly fine for me for bootstrapping a Visual Studio 2017 build of Premake.

Done Building Project "D:\dev-premake\premake-core\build\bootstrap\Premake5.sln" (default targets).


Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:46.35

D:\dev-premake\premake-core>

[tvandijck]

@starkos In my opinion the sensible default is to not emit the property.

If I create a new Console Application, it emits this to the vcxproj file.

<WindowsTargetPlatformVersion>10.0.16299.0</WindowsTargetPlatformVersion>

Which appears to be the latest I have installed on my desktop, and only available reliably through the registry, but it also makes the vcxproj file completely non-transferable. Anyone not having that SDK installed will have to update that property. Generating a Visual Studio project from linux/mac would also be impossible since no such registry setting is available.

I think to come up with a proper solution, more testing is required to see how Visual Studio deals with all these issues.

[dcourtois]

I don't mind looking up the value where it is possible, but there needs to be a solution for people generating projects from Linux and macOS too.

But those people will generate a project that does not compile on Windows machines with Visual Studio 2017 and SDK 8.1 installed (because the generated project uses toolset v140 and default sdk, which is 8.1 when it's installed, and those 2 are incompatible, see my previous comments) !

Like @tvandijck says, the most sensible thing in my opinion is to try to look this up, only if the user didn't explicitly set it, and only in the specific case of vs2017 with the v140 toolset and if it's not found, then just do nothing at all : it's the current behavior, so you won't introduce any regression.

This proposition should only fix the basic cases where the projects are generated on the machine used to build, which I think is the majority of use cases. And for all the other cases, it will not change anything at all.

@tvandijck : I didn't know the MSDEV option to the bootstrap Makefile, I'll try that tomorrow, but I don't understand how it could correctly set the correct sdk version (since premake doesn't specify it, and the devenv /upgrade command used by the Makefile should not upgrade the sdk version since it's not there in the projects). Do you have both 8.1 and 10.0 SDKs installed ? Cause I think that if there is only the SDK 10 installed, Visual Studio will correctly set the correct platform version (this whole issue comes from having both SDKs installed, and Visual Studio 2017 using version 8.1 as its default, which is totally stupid, but ... :p)

[tvandijck]

@dcourtois yes I do have both 8.1 and 10 installed. I am however using the 'windows-msbuild' target, not the 'windows' target... the msbuild target skips the upgrade step, and uses msbuild directly to build, instead of msdev.. Although when specifying the MSDEV option, the upgrade should be a no-op.

[ratzlaff]

but there needs to be a solution for people generating projects from Linux and macOS too.

I have nothing really to add except that we use this feature of premake at my company (just yesterday actually). It saves so much time when you are not a master of windows cmd.

[dcourtois]

@tvandijck Back to work on Windows ! I just tried your command line, but unfortunately it still doesn't compile. Here are the two lines I'm using:

D:\Development\Premake\premake-core> "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat"
D:\Development\Premake\premake-core> nmake -f Bootstrap.mak MSDEV=vs2017 windows-msbuild

And the compilation fails with a ton of headers not found. I checked with the x86 version of vcvars, it's the same. And as expected when I opened the solution with Visual Studio 2017 (build\bootstrap\Premake5.sln), all projects are incorrectly setup: Platform Toolset is v141, but Windows SDK Version is 8.1, leading to the broken build.

It's surprising that it builds fine for you ... would you mind telling me how toolset and sdk version are setup in your generated build\bootstrap\*.vcxproj projects ? And when you open the solution, what sdk version is selected ?

[samsinsane]

Out of curiosity, I looked into the issue of VS2017 generating a broken 8.1 install. Super simple fix - Install Windows 10.0.10240.0, both VS2015 and VS2017 use 10.0.10240.0 for some of the headers, specifically this folder: C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt. I noticed this on my tablet, which I thought had VS2017, but it doesn't - just VS2013 and VS2015.

Ultimately, both of these issues are bugs in Visual Studio, not Premake. Visual Studio installs half of the 8.1 SDK, Visual Studio picks the 8.1 SDK as the default even if it's not installed. Premake shouldn't start defaulting settings just because the tools contain bugs, especially when the default value changes depending on what is installed on the system.

Perhaps setting systemversion "latest" could do some magic and select the latest macOS, iOS and Windows versions, but users should be making the decision to do this.

Thinking about this a bit more, maybe Premake could provide a bit of a warning, more of a heads up, if it can't detect the 10.0.10240.0 and 8.1 SDKs and the project doesn't specify systemversion? Maybe if the project is being generated from a non-Windows system too and the systemversion isn't specified? Not super sold on that last bit, but an informative warning is more useful than attempting to build and getting told stddef.h doesn't exist.

[dcourtois]

but users should be making the decision to do this

but the users currently have a broken build ... I utterly fail to see the point of forcing the user to update their scripts and specifically set a systemversion "latest" in a case where we know with absolute certainty that the solution won't build at all ! What's the point of not fixing something we know is broken ? Users already using systemversion will not be impacted, and the ones not using it will suddenly have something that works. And the ones that generate for vs2017 on another platform will still have a solution that doesn't build, but this is already the case.

No matter how I look at it, the worst case scenario is : it won't change a damn thing, the solution will still be broken, and in some cases : the solution will build out of the box. Where's the problem ?

Even CMake correctly sets the WindowsTargetPlatformVersion property in the generated .vcxproj files.

Note : I understand the concerns about starting to default some settings. But in this case the default are actually broken ! And I would also like to point out that Premake already does this for some other properties, like the toolset one for instance : PlatformToolset is actually set in the generated .vcxproj even if not setting is perfectly valid. So why defaulting that one, but not WindowsTargetPlatformVersion, especially when specifying the first and not the second result in a broken build ?

Note 2 : Leaving PlatformToolset empty in a .vcxproj falls back to v100 toolset. And this toolset is actually compatible with the default SDK Version (8.1) And using the retarget tool on such a project works perfectly. I guess this is why Premake's generated projects are broken : those 2 properties are not meant to be half specified : either set toolset and sdk version are do not set any of those.

[samsinsane]

@dcourtois I can build with both v141 and the 8.1 SDK. Just install the 10.0.10240.0 SDK and the 8.1 SDK will work. This is an issue with Visual Studio, not Premake.