I'm trying to install CUDA, but I get a message saying "No supported version of visual studio was found". I think that this is because I am using Visual Studio 2017 (Community), and CUDA currently only supports up to Visual Studio 2015. Unfortunately, Microsoft will not allow me to download old versions of Visual Studio without paying a subscription fee.
Is there a way I can get around the compatibility issue with VS 2017, or can I not use CUDA?
If you want to install CUDA 8.0 with Visual Studio 2017 you need to install additional components for Visual Studio 2017.Click on the Start Menu and type Visual Studio Installer. Open Visual Studio InstallerOpen Individual components tab and select VC++ 2015.3 v140 toolset
under Compilers, build tools and runtimes.
You also need to install .NET Framework 3.5 if you didn't have it installed. Nvda.Build.CudaTasks.v8.0.dll assembly dependents on MS .NET Framework 3.5.
Open Classical Control Panel, go to Programs and features and press Turn Windows features on or off. Check .NET Framework 3.5 and press OK.
Download full CUDA toolkit distribution and extract it somewhere on your disk.
If you didn't have CUDA toolkit installed, do it now. If you have only Visual Studio 2017 installed, unselect Visual Studio integration checkbox.
Now you want to receive the "No supported version of the visual studio was found" error.
But in order to successfully build Cuda toolkit projects in Visual Studio 2017, you also need to follow steps 5 and 6.
Go to the CUDAVisualStudioIntegration\extras\visual_studio_integration\MSBuildExtensions folder in your extracted distribution, copy all the files and paste them to C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\v140\BuildCustomizations:
In the last step, you will need to edit your Cuda projects to recognize NVidia's build tasks from Visual Studio 2017. Open your .vcxproj file in a text editor and find all occurrences of CUDA 8.0.props. Replace the macro at the beginning of the string with $(VCTargetsPath14) so that XML snippet would look as follows:
<ImportGroup Label="ExtensionSettings">
<Import Project="$(VCTargetsPath14)\BuildCustomizations\CUDA 8.0.props" /></ImportGroup>
Don't forget to edit the custom targets path at the end of the file:
<ImportGroup Label="ExtensionTargets">
<Import Project="$(VCTargetsPath14)\BuildCustomizations\CUDA 8.0.targets" /></ImportGroup>
Make sure to double check your path conifuration!
If you use nvcc from command prompt you might not be calling cl.exe from Visual Studio folder!
Now you can build your Cuda project from Visual Studio 2017.
Parts of this solution are from Oleg Tarasov blog.
At the moment, Microsoft still seems to be making VS2015 Update 2 community edition available. You have to join the "dev essentials" program, but it seems to be free.
I was able to download the installer from here recently.
Update: CUDA 9 RC was made available yesterday at developer.nvidia.com to registered developers, and it has support for VS 2017.
Thank you everyone for your help. I just wanted to supplement this post with the last pieces of the puzzle. CUDA v9.0 RC is looking for VS2017 to identify as 1910 but the latest update actually identifies as 1911. To fix open .../CUDA/v9.0/include/crt/host_config.h and change this line:
#if _MSC_VER < 1600 || _MSC_VER > 1910
to this:
#if _MSC_VER < 1600 || _MSC_VER > 1911
You may also have to add the following to your CMakeLists:
list(APPEND CUDA_NVCC_FLAGS --cl-version=2017)
For people seeing this latter.
First, try to just install CUDA 10 (CUDA Toolkit 10.0).
If it still doesn't work without any mods make sure that you have as many VC++ toolsets as you see on the list. Check out this video, stop at 8:41 and compare the lists.
If for some reason you have to use CUDA 9.0 - 9.2 you will need to jump some hoops:
For cmd builds set vcvars_ver=14.11 - see this answer
For IDE builds set Platform Toolset (in project properties - General) to
Visual Studio 2017 (v141)) or
Visual Studio 2015 (v140))
If you have very customized cmd based build, hunt #if _MSC_VER (in .../CUDA/.../include/crt/host_config.h) and remove trailing || _MSC_VER > ...
In order to get working Cuda compiler nvcc in windows shell you need to do following
install proper toolset version from individual component for VS 2017 - VC++ 2017 version 15.4 v.14.11 toolset
Run in windows shell following "c:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x64 -vcvars_ver=14.11
You can compile nvcc code without errors from windows shell
I ran into the same issue using CUDA 9.1 and VS2017 Enterprise.
After changing the VC++ compiler to v140 (instead of 141) everything runs fine.
Already had flags
#if _MSC_VER < 1600 || _MSC_VER > 1911
But it wouldn't stop showing the error.
No idea why, but trying to run it on VS2015 lead to errors about v141 not being installed... so because of some twisted logic I tried to not use v141 where it was installed... and everything worked!!
Leaving this here as it may help someone else in the same situation. (although I really don't understand the why, how, when, who or what of the solution.
Latest update (correct as of 06/12/2018) latest Cuda version is 9.2 and latest Visual Studio version is 2017.7 do NOT work together. The instructions provided in solution above don't work. Here is what worked for me:
Uninstall Visual Studio.
Uninstall Visual Studio Installer
Download Visual Studio 2017.6 (note that Microsoft is known to change links and revisions without notice) https://learn.microsoft.com/en-us/visualstudio/productinfo/installing-an-earlier-release-of-vs2017
Launch installer
Go to Individual Components. Click on Windows 10 SDK 10.0.15063
enter image description here
Download cuda Toolkit from the official website: https://developer.nvidia.com/cuda-downloads?target_os=Windows&target_arch=x86_64&target_version=10&target_type=exelocal
You may need to download patch.
I wanted to edit my CUDA programs using a text editor (i.e. Sublime) and compile them from the command prompt but I ran into an nvcc compiler error. I installed Visual Studio 2017 with Windows 10 OS but after compiling, it said "only version of VS 2012, 13, 15 and 17 are allowed." So what I did was to intall VC++ 2015 toolkit from the installation package of the VS 2017 installer (refer to the image of the top post). I didnt go through his entire process instead, I only copied the path of my cl.exe file from the newly created VS 14.0 folder to the environment variable. The .exe can be found here:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin
Hope this helps!
Just as update. My compatibility is:
Cuda version 11.2
Visual Studio Community 2019
I'm going to use the HelixToolkit.SharpDX with VS2017 in my Windows 10 workstation, when I attempt to build the solution, it will prompt the Assertion Failed error with "No fxc.exe found".
I have checked the installation option, Windows SDK has been included, nand I have downloaded and install again, and I can see the fxc.exe in "C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x64" & "C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x86" folders, so it should be available for any windows version, but unfortunately, the same error reported.
However, I have also installed VS2017 in another Windows 7 machine, it works fine, and it has the fxc.exe in the same folder as my Windows 10 workstation, but it can be located by VS2017.
Is there any setting in VS2017 to locate the fxc.exe?
Or how can I fix this issue?
Copy fxc.exe in Bin\10.0.xxx\x86 to Bin\x86 to fix this issue. Because the HLSL compile tool hard coded the path.
One can find solution on helix toolkit github page.
Visual Studio 2017. Windows 10 SDK.
Missing fxc.exe issue with newest Windows 10 SDK:
Copy fxc.exe in C:\Program Files (x86)\Windows
Kits\10\Bin\10.0.xxx\x86 to C:\Program Files (x86)\Windows
Kits\10\bin\x86 to fix this issue. Because the HLSL compile tool hard
coded the path.
This seems to have been fixed in Visual Studio 2019 16.0.2, as of writing. Just have to make sure $(WindowsSDK_ExecutablePath) is pointing to the correct SDK directory and the build version that matches with the Targeted Platform in the Project Properties page.
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/a3032567-d8e7-4b01-81b7-0612047a6299/why-do-we-need-to-copypaste-fxcexe-from-bin100xxxxx0x86-to-binx86-directory-in-the?forum=windowssdk
Second post answered:
The executables that the C++ build process uses from the Windows SDK directory are MIDL.exe, MT.exe and RC.exe. If you digitally sign your executables then you will find signtool.exe here too. So I am kind of surprised that it finds some critical build tools correctly but others it fails to find.
My suggestion would be:
1) Verify that you are having this problem with your project in Visual Studio 2019 16.0.2 (the latest version at the time of writing) or Visual Studio 2019 Preview (16.1 Preview 1 at the time of writing). This is to check that if this has been found to be a bug, then it could have been fixed.
2) Create a completely new project. Without touching the project's executable path, try to create a sample that shows this behaviour. It doesn't need to be a full sample, just complete enough to show that Visual Studio fails to find fxc.exe.
3) If doing all of this shows that Visual Studio fails to find fxc.exe, then through Visual Studio 2019, report it as a bug.
But I will mention that a naïve test on my end shows that Visual Studio 2019 can compile HLSL shaders without any issues using the 18362, 17763 and 17134 SDKs. These were tested because these are the versions that I have installed.
After installing Visual Studio 2015 and running CMake on a previous project, CMake errors stating that it could not find the C compiler.
The C compiler identification is unknown
The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:4 (PROJECT):
No CMAKE_C_COMPILER could be found.
CMake Error at CMakeLists.txt:4 (PROJECT):
No CMAKE_CXX_COMPILER could be found.
I went searching for cl.exe in the Visual Studio folder,C:\Program Files\Microsoft Visual Studio 14.0, and could not find it.
How do I set up CMake to work on Windows with Visual Studio 2015?
I have found the solution. While the Visual Studio IDE installed successfully it did not install any build tools and therefore did not install the C++ compiler.
By attempting to manually create a C++ project in the Visual Studio 2015 GUI I was able to prompt it to download the C++ packages. CMake was then able to find the compiler without any difficulty.
Here is the solution that worked for me:
Open Visual Studio command prompt tool (as an administrator). On windows 10 it might be called 'Developer command prompt'.
Navigate to where you have the CMake executable
Run Cmake.exe
Proceed as usual to select build and source folder
Select the appropriate Visual Studio compiler and hit the configure button
Hopefully it should run without problems.
I looked in CMakeError.log file and found an error about cannot run 'rc.exe'
I searched and found this answer to copy RC.Exe and RcDll.Dll from the Microsoft SDKs bin to the VC bin, and then CMake worked.
Edit: The top answer to another question suggests that it's a PATH issue, so it could be enough to ensure the Microsoft SDK bin is in your PATH.
Those stumbling with this on Visual Studio 2017: there is a feature related to CMake that needs to be selected and installed together with the relevant compiler toolsets. See the screenshot below.
Make sure you are using the correct version of Visual Studio in the generator. I had incorrectly selected Visual Studio 15 when Visual Studio 14 installed.
If none of the above solutions worked, then stop and do a sanity check.
I got burned using the wrong -G <config> string and it gave me this misleading error.
First, run from the VS Command Prompt not the regular command prompt. You can find it in
Start Menu -> Visual Studio 2015 -> MSBuild Command Prompt for VS2015 This sets up all the correct paths to VS tools, etc.
Now see what generators are available from cmake...
cmake -help
...<snip>...
The following generators are available on this platform:
Visual Studio 15 [arch] = Generates Visual Studio 15 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 14 2015 [arch] = Generates Visual Studio 2015 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 12 2013 [arch] = Generates Visual Studio 2013 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 11 2012 [arch] = Generates Visual Studio 2012 project files.
Optional [arch] can be "Win64" or "ARM".
Visual Studio 10 2010 [arch] = Generates Visual Studio 2010 project files.
Optional [arch] can be "Win64" or "IA64".
...
Then chose the appropriate string with the [arch] added.
mkdir _build
cd _build
cmake .. -G "Visual Studio 15 Win64"
Running cmake in a subdirectory makes it easier to do a 'clean' since you can just delete everything in that directory.
I upgraded to Visual Studio 15 but wasn't paying attention and was trying to generate for 2012.
For me, I checked the CMakeError.log file and found:
[...] 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 is despite using Visual Studio 2017 on Windows 7. So it appears that CMake is trying to build its detection project with the Windows 8.1 SDK.
I used the Visual Studio installer to add that component and now CMake is happy as a clam.
Menu → Visual Studio 2015 → MSBuild Command Prompt for Visual Studio 2015. Then CMake can find cl.exe.
set PATH="c:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x64\";%PATH%
Change the upper path to where your Windows SDK is installed.
CMake can find rc.exe.
cd to the path of CMakeLists.txt and do:
md .build
cd .build
cmake .. -G "Visual Studio 14 2015 Win64" -DCMAKE_BUILD_TYPE=Release
cmake --build .
The param after -G should be fetched by CMake. Use --help; you may or may not have the generator.
I ran into the same issue and fixed it by relaunching the Visual Studio Install and checking the following option:
Windows and Web Development / Universal Windows App Development Tools / Windows 10 SDK
It contains the standard C++ headers used in most applications and therefore it is often necessary to install it as well.
I had this issue under Windows 10 when using Visual Studio 2015 Professional, while Visual Studio 2015 Express worked! Under Windows 7, both Visual Studio versions used to work.
New projects created from the Visual Studio 2015 Professional IDE successfully compile, but CMake would fail to find the compiler reporting:
The C compiler identification is unknown
The CXX compiler identification is unknown
I upgraded CMake from 3.4.1 to 3.11.4, and now the problem is gone.
If you are on Visual Studio 2017 you need at least CMake 3.8!
I had a similar problem with the Visual Studio 2017 project generated through CMake. Some of the packages were missing while installing Visual Studio in Desktop development with C++. See snapshot:
Visual Studio 2017 Packages:
Also, upgrade CMake to the latest version.
Checking CMakeErrors.log in CMakeFiles returned:
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\x64\PlatformToolsets\v140_xp\Toolset.targets(36,5): warning MSB8003: Could not find WindowsSdkDir_71A variable from the
registry. TargetFrameworkVersion or PlatformToolset may be set to an
invalid version number.
The error means that the build tools for XP (v140_xp) are not installed. To fix it I installed the proper feature in Visual Studio 2019 installer under Individual Components tab:
I was running old cmake version (i.e. 3.8) and I'm using visual studio 16 - 2019. After updating my cmake version, it did detect the compiler.
In my case there was an environment variable set which was the reason for this error.
The problem was solved after deleting cxx_flags from the environment variables.
I got this problem with CMake 3.12.1, after an update of Visual Studio 2017. I simply re-ran CMake and it worked.
In my case I could see in the CMakeError.log that CMake could not find the Windows SDK (MSB8003: Could not find WindowsSDKDir variable from the registry).
The version can be specified on the commandline on the first CMake run using:
-DCMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION=
I got further after setting that, but I hit more issues later (so I assume my environment is messed up somehow), but maybe it will help someone with this issue.
A couple of tips:
Try to set the path manually by checking 'advanced' and modifying CMAKE_LINKER and CMAKE_MAKE_PROGRAM
Delete the cache - in the CMake with GUI go to:
File → Delete Cache.
My problem was a combination of previously stated: I have set the compiler version to 15 instead of 14 and when corrected, I had to delete the cache.
I also started the Visual Studio command prompt as an administrator and from there I ran the cmake-gui.exe
Then everything worked as it was supposed to.
In my case the issue was that the parent project, which is including googletest via
add_subdirectory(gtest_dir)
was defined as
PROJECT( projname CXX )
Somehow, CMake does not recognize
PROJECT(sub_project_name CXX C)
since the C compiler is not set in the parent.
I solved the issue by using
PROJECT( projname CXX C)
in my main CMakeLists.txt file.
This might be another solution for those with the latest Windows 10 creator version:
Stack Overflow post Fatal error LNK1104: cannot open file 'gdi32.lib'
None of the previous solutions worked for me. However I noticed that although I installed Visual Studio version 15 (not to be confused with Visual Studio 2015) the directory created on my computer was for Visual Studio 14.
When I specified Visual Studio 14 when I pressed the configuration button it worked.
i found this sollution at stackoverflow and i work for me although not working other sollutions
if you have a windows 10 OS, doing the following steps will fix the problem:
1) go to C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin
2) then copy RC.exe and RcDll from this file
3) go to C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin and paste the two files you have copied into it.
thats all i hope it is helpful...
Look in the Cmakelists.txt if you find ARM you need to install C++ for ARM and as well vcvarsall.bat use for ARM bin folder.
It's these packages:
C++ Universal Windows Platform for ARM64 "Not Required"
Visual C++ Compilers and libraries for ARM "Not Required"
Visual C++ Compilers and libraries for ARM64 "Very Likely Required"
Required for finding Threads on ARM
enable_language(C)
enable_language(CXX)
Then the problems might disappear:
No CMAKE_C_COMPILER could be found.
No CMAKE_CXX_COMPILER could be found.
If above does not resolve your problem?
Optionally you can remove the options C and CXX in cmakelists.txt by setting # infront of where the enable_language(C) is. And avoid Android ARM processor compilation.
Resolved by adding the missing component
Modify->continue add as follow
I had a related problem: the Visual C++ generators were not even on the list when running cmake --help.
I ran where cmake in console and found that cygwin also provides its own cmake.exe file, which was being used. Changing the order of directories in PATH fixed the problem.
I had this issue with CMake GUI and the VS 21019 Community Edition. I think I may have installed CMake before Visual Studio - certainly after I updated CMake 3.15.2 to 3.15.3 the problem went away.
Check name folder too long or not.
This question is old, but none of the solutions here were working for me. I'm using Visual Studio 2019, and in my case, C++ compilation was working but just broke one day.
However, I noticed that there was an update ready to be installed in the Visual Studio Installer.
After installing that update, rebooting my computer, and relaunching Visual Studio, all of the C++ CMake problems disappeared. I'm not quite sure why this fixed it, and I can only speculate, but I can only assume that one of two things occurred. Either installing that update fixed a broken installation, or the update was quietly downloaded and prepared in the background, breaking things in the process.
I met the same issue in VSCode Cmake extension, i solve it by check following two options:
In the end, click [Scan for kits]
cmake --no-warn-unused-cli -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug "-DCMAKE_C_COMPILER:FILEPATH=C:\Program Files\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin\gcc.exe" "-DCMAKE_CXX_COMPILER:FILEPATH=C:\Program Files\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\mingw64\bin\g++.exe" -Hc:/code -Bc:/code/build -G "MinGW Makefiles"
I have a fresh Windows 8.1 Pro x64 install with a fresh Visual Studio 2013 Pro.
When trying to compile a project with Platform Toolset to Windows7.1SDK I'm getting
Error 1 error MSB6006: "CL.exe" exited with code -1073741515. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.targets 57 5 MenuBrowser
I tried running the supplied "Windows SDK Configuration Tool" and besides getting an error about Visual Studio 2005 and 2008 not being installed I think it did its job.
I tried manually editing the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows
where I manually put CurrentInstallFolder as C:\Program Files\Microsoft SDKs\Windows\v7.1\ and CurrentVersion as 7.1.7600.0.30514. If I look at the project properties and click the different paths / variables in there -> more -> Macros, I can see that $(WindowsSdkDir) is correct.
Any idea as to what I should try? Never ran into this problem on the old development computer with Windows 7 and VS 2012.
L.E. as a note, if I try a new project with the v120 tools, it works, but I need the Windows7.1SDK tools.
When trying to compile a project with Platform Toolset to Windows7.1SDK...
That's not a valid selection in a "fresh" install for VS2013. Not very clear what you've been doing, it certainly isn't "fresh" anymore. Do treat Regedit.exe as a loaded weapon, the registry key set that configures VS has been getting pretty doggone convoluted as of late.
The compiler crashes with -1073741515 == 0xC0000135 == STATUS_DLL_NOT_FOUND. That's a pretty serious mishap of course, it should never occur when you target SDK 7.1 since that still uses the same compiler, only the SDK directory is changed. The compiler itself, as well as the DLLs it uses, are not part of the SDK and only are provided if the machine doesn't have VS installed. You can use SysInternals' Process Monitor to diagnose this, you'll see the CL.EXE process searching for a DLL and not finding it.
The correct way to target 7.1 is to use the v120_xp toolset selection. That builds programs that can still run on XP, it automatically also selects the 7.1A SDK that was installed on your machine. Do try to undo the changes you've made.
Referencing Yodans solution from
How to build with v90 platform toolset in VS2012 without VS2008, using Windows SDK?:
As pointed out by Hans Passant cl.exe looks for mspdb100.dll (among others) and does not find them.
The needed files are in the directory mentioned in 7. below:
My working setup:
VS2013 needs to use VS2010 libs
Using WinSDK 7.1 build tools (v100) in VS2013
clean install, uninstalling everything mentioned in the sdk release notes (can be downloaded at http://www.microsoft.com/en-us/download/details.aspx?id=8279 under category Details)
Microsoft Windows SDK for Windows 7 (7.1) (the Windows SDK core-component files)
Application Verifier
Debugging Tools for Windows
Windows Performance Toolkit
Microsoft Help Viewer 1.0
Microsoft Visual C++ 2010 Redistributable
Microsoft Visual C++ 2010 Standard Edition
Additionally removed all .NET and VC++ related MS Software (not tested if necessary)
choosing Windows7.1SDK as Platform Toolset in VS2013
error MSB6006: "CL.exe" exited with code -1073741515
cl.exe looks for one of msobj100.dll, mspdb100.dll, mspdbcore.dll and mspdbsrv.exe
Added to PATH: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
Build works and binary is usable!
A mistake I did:
copied files in 6. above to C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin, believing this directory is in PATH, but it was not!
So better do as sugested in 7. above or by Yodan in How to build with v90 platform toolset in VS2012 without VS2008, using Windows SDK?
The following steps work for me in VS 2017.
1.Close VS 2017.
2.Restart machine.
3.Open solution in VS 2017.
4.Build the project.
This time I didn't get following error and it builds successfully.
error msb6006 "link.exe" exited with code -1073741819.