I did a fresh install of Visual Studio Community 2017 today so that I could start using JUCE. I’m currently receiving the messages “‘corecrt.h’ file not found” and “‘windows.h’ file not found”
I’m not entirely sure why, but my best guess is that something was not included in the workload packages that I selected. I am looking at practicing making an audio plugin, and was wondering if somebody could help get me up and running?
Thanks in advance.
I guess you selected the
Desktop development with C++ workload. This includes the
Windows 10 SDK (10.0.17134.0) component.
In Projucer, the
Windows Target Platform setting (located in the
Visual Studio 2017 exporter settings) is set to
10.0.16299.0 by default.
Now you have 2 solutions:
- either launch
Visual Studio Installer and modify your installation by adding the
Windows 10 SDK (10.0.16299.0) for Desktop C++ [x86 and x64] component
- or change the
Windows Target Platform of your project to
There is an unofficial trick to set the platform SDK to the latest 10.x available. I think this is what the projucer should use to avoid all these issues with moving versions of the SDK.
Which is?.. If it’s something we can add to the Projucer that would be great, getting the correct Windows SDK is a real headache.
I have to look it up tomorrow… I don’t use it myself, have to find it again
<WindowsTargetPlatformVersion Condition="'$(WindowsTargetPlatformVersion)' == ''">$([Microsoft.Build.Utilities.ToolLocationHelper]::GetLatestSDKTargetPlatformVersion('Windows', '10.0'))</WindowsTargetPlatformVersion>
Thanks! I’ll do some tests and add it in if it’s working OK.
Did this ever get added in? Just did a fresh install today of Visual Studio Community 2017 on Windows 10 today (downloaded here), and getting this same error as the OP. Thanks!
A bit more detail on the issue, and a workaround:
As McMartin had guessed about the OP’s setup, I also had selected the
Desktop development with C++ “Workload” in the Visual Studio 2017 installer/setup app.
Here are the details on that:
So, as you can see, the current Windows 10 SDK is
With the version of Projucer downloaded from
juce.com, I get these “file not found” errors:
So then I decided to try rebuilding Projucer locally, which worked. And the locally-built Projucer loads up the JUCE example projects without any “file not found” errors, and from there they build successfully in Visual Studio. Opening the Juce file again in the downloaded version of Projucer still shows the ‘file not found’ errors.
The two versions of Projucer I have now (downloaded and built) have the same version number (
5.4.1) but different file sizes (downloaded shows as about 9.2 MB, built shows as about 17.9 MB).
All this said, I’m pretty out of my element on the Windows side of things, so I can’t say with certainty what’s happening. Just hope the facts here will help someone else figure it out.
Using the Live Build Engine in Projucer is not the same as using Projucer to generate a Visual Studio solution. Even if both happen in Projucer, they are totally disconnected.
The trick that @Matthieu_Brucher mentioned (which was added to Projucer in https://github.com/WeAreROLI/JUCE/commit/bb0a0d3cb6a96ee45a2ea3c2ba94eceab20f0a14) doesn’t have any effect on the Live Build Engine.
@ed95 which version of the Windows 10 SDK should @leigh install to be able to use the Live Build Engine? Please write it down somewhere in Projucer or on the JUCE website.
This sentence is very confusing to me. What are you trying to use? the Live Build Engine? Visual Studio? both?
I guess that’s because you built Projucer locally in Debug configuration. The downloaded Projucer was most certainly built in Release configuration.
You shouldn’t need a specific version of the Windows 10 SDK as long as at least one is installed via the “Desktop development with C++” option". @leigh where have you installed Visual Studio on your machine? Is it in the standard installation location on your C:\ drive?
To clarify - I wasn’t using the Live Build Engine to actually build anything, I was just noting the errors it listed.
You say they are “totally disconnected” - I believe that the build processes are disconnected. However, when using Projucer to generate a Visual Studio solution, Projucer needs to know where the SDKs are, so it can pass that information along to VS, right?
Ah, sorry, there was some confusion on my part. I was using Visual Studio for my builds. And I was comparing the behavior of the locally-built Projucer (i.e. the Projucer build I created), versus the Projucer build I downloaded. HOWEVER, I was not making a fair comparison. The reason that the one Projucer build showed no “file not found” errors was that I hadn’t enabled the live-build engine on it. Whoops. I’m new to using Projucer, and I had wrongly assumed that checking for the existence of files was independent of using the Live Build Engine. And therefore since I didn’t see a red flag go up in the live build tab:
…I assumed that it had found all the files just fine. Wrong. The reason I didn’t see that warning flag was that I hadn’t yet downloaded/enabled the Live Build Engine in that copy of Projucer. If this is still confusing, please just disregard.
Hi Ed - yes I believe Visual Studio is in the standard location. As I mentioned, I’m out of my element in Windows, so I generally go with the default installs.
Visual Studio is here:
C:\Program Files (x86)\Microsoft Visual Studio
The Windows SDK files are here:
C:\Program Files (x86)\Windows Kits\10
For example, here’s one of the specific files that Projucer says it can’t find:
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\Windows.h
And here is the other:
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\ucrt\corecrt.h
There are perhaps other versions of these files on disk, but due to the Windows File Explorer’s terrible Search behavior, they are hard to locate. (Searching for
windows.h, even in quotes, produces a gazillion results, including
windows.system.diagnostics.telemetry.h, etc etc etc.
Googled and found that you can do exact filename match searches in the Windows 10 File Explorer using the syntax
name:=Windows.h. How intuitive.
Can you try changing the
Windows Target Platform setting in the live-build settings to
10.0.17763.0 like so:
Yes, that worked to clear the “file not found” errors, thank you.
It also points out something that wasn’t clear to me before - that there are separate “Windows Target Platform” fields found in the Exporters and the Live Build settings. I had figured it would just be set once for a given project. I had already tried changing the “Windows Target Platform” in the Exporter setting, but that (of course it’s clear now) didn’t fix those “file not found” errors in the Live Build view.
Anyhow, is the Live Build engine supposed to automatically find the latest installed SDK, or is it normal to have to manually enter it like I just did?
The Live Build Settings and the Exporters are totally disconnected, really. Projucer can’t re-use “Windows Target Platform” from the Exporters in the Live Build Settings for the simple reason that you can have as many Visual Studio 2017 exporters, with potentially different values for “Windows Target Platform” as you want:
The Live Build Engine doesn’t find the SDK, it only tells Visual Studio which version to use (as a string), and Visual Studio deals with it.
Got it now. Thanks for explaining.
Thank you very much for the troubleshoot!!! Seriously, the settings change worked like a charm.
Forgive me to ask a noob question, maybe its already answered somewhere, but can you explain why there is so much disparity with the change in address (i’m not even sure if its called address )… I do sort of understand that in order for the projucer to link the VS exporter properly, there is a dependency on the address to the VS, especially if a user has multiple VS versions… but shouldn’t projucer be able to handle the target platform automatically , depending on the exporter choice???
I reinstate that I am a complete noob, and probably I might be missing a lot of things, but please enlighten me, I’m here to learn!!!
Thank you in Advance!!!
The live-build engine requires the Windows runtime libs and headers that are located in the Visual Studio install folder in a subdirectory with the SDK version number. This was simpler pre-Win10 because there was only ever an “8.1” SDK, however in Windows 10 each version of the SDK has a unique version number (like “10.0.17763.0”) so we need to know this string when adding the search paths in the live-build engine otherwise you end up with the errors above.
Thank you very much for your reply!!!
But isn’t it odd that one needs to have the knowledge of the SDK version number in order for projucer to link to the right windows folder containing the libs and headers??… Shouldn’t this be done automatically ?? ….
When you say “each version of the SDK”, you mean different Windows SDK versions, or for the target platform chosen when creating a new project, or both??