Hi,
for some reason it helps me when I run visual studio as Administrator. Even though my user already has admin rights, visual studio still needs to be run as admin.
Also set platform toolset to v140 under project settings
That’s how I got it working and avoided constant expression errors…
Using Visual Studio 2017, at Cpp Project Properties → General → Plattform Toolset settings you get v141.
It is not v120 what stands for Compatibility Vs 2013.(we want use 2017 no old compatibility big installs)
We are waiting for Update of Cuda 9.1++ with Vs2017 v141(c++ compiler tools).
Hello,
Even I had this same problem, I cannot find any solutions.
I have the latest visual studio community 2017. I cannot figure out what to do
Visual Studio community 2017 . 15.6. Tried with Cuda9.0 and 9.1, but no help. Any suggestion?
I’ve been following this issue since December. Interesting to see it has taken this long (and who knows how long more) to resolve.
[url]How to get Visual Studio 2017 to use CUDA 9.1? - CUDA Setup and Installation - NVIDIA Developer Forums
External Media
Reinstall Windows10, than install previous Vs2017 15.4.5 En(because of Vs2017 only c++ compile tools not c++ Vs2015!), install Cuda 9.1 + patch 3. Update Driver 391.01. Just like friend vote and comment by adding a post, if it also works now fine for you, too.
Has anyone had any success by compiling with the toolset of version v140 with Visual Studio 15.5? It seems that version of the cl (19.00) is suitable for CUDA 9.1 when using this toolset. However, when i tried to change the toolset version, i got a missing build customization error - for some reason CUDA .props file was not there for v140 toolset (should be located at C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\BuildCustomizations), so, i copied the ones from \Common7\IDE\VC\VCTargets\BuildCustomizations but then again, i got an error from that .props file. So i am wondering, am i missing appropriate build customization files, would CUDA toolkit reinstall help?
Update: so i reinstalled CUDA and it did the trick. I am able to successfully compile and run projects with v140 toolset with VS 15.5. I also managed to get it working with CMake. -T and -G give the ability to specify exact generator and toolset. Here’s what worked for me:
cmake -G "Visual Studio 15 2017 Win64" -T v140,host=x64 path_to_src/
I have the same issue, I have tried each of the solutions in this thread and nothing has worked for me :(
NVIDIA or Microsoft have plans to correct this?
I was able to get VS 2017 Community working by running the Visual Studio installer and installing then using 1.40 tool set.I would be interested to know if anyone can compile with the 1.41 tool set.
If it helps anyone, I was able to compile bandwidthTest from CUDA v9.2 on Windows 10 Pro (Version 1803) with VS 2017 15.7.2 (VC++ 2017 version 15.7 v14.14 latest v141 tools) by
changing line 131
in “C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.2\include\crt\host_config.h”
to #if _MSC_VER < 1600 || _MSC_VER > 1914
from #if _MSC_VER < 1600 || _MSC_VER > 1913.
The right fix is to release a new CUDA which is current with the latest MS Visual Studio 2017… is there a webpage to file bugs against CUDA available?
6/12/2018 update
Latest Visual studio version 2017.7 is not supported by latest Cuda 9.2 version.
The easiest thing to do is this:
Anybody from nvidia looking at this forum? I just wasted my entire morning trying to get Cuda 9.2 samples to compile with the latest visual studio community edition 2017.7.
It’s just insane. Can you just release a new version of CUDA that is compatible with VS 2017?
Fair comment. As far as I know Nvidia has this coming soon, but not quite ready yet. THe solution that worked for me is moving back to 2017.6.
Its absurd…
The first recorded occurrence of this issue was 08/16/2017 04:49 AM, sure there is a work around but a year later?
I have to be honest it isn’t much better on Linux, I tried a few of the “Suggested” popular distributions, all of these distributions have moved on and are no longer compatible at the kernel level with the drivers. I was forced to download and install CentOS 7 and do a bit of brain surgery to get the driver to install by removing nouveau.
Come on nVidia… you need to clean this up.
感谢楼主给予的解决思路
It’s Nvidias fault 100%. It’s a simple fix to change the compatibility check to be a major version of VS not a minor version. Just look for 15.* instead of 15.1,15.2,15.3,15.4,15.5,15.6,15.7
This way you don’t screw over your Windows users every time there is a patch!
It’s standard to keep your tools up to date. So saying USE AN OLDER VERSION is ridiculous and unprofessional.
Any of the millions of programmers know how to do this. yet nvidia lives in some bubble for years and gives us this problem forcing us off Windows onto Linux terminals. which is just inefficient.
If NVIDIA did that, there is a good chance that one of these two scenarios would occur:
(1) After a Microsoft patch update, all (or most) of your CUDA builds suddenly fail with a slew of incomprehensible error messages fro m MSVC
(2) After a Microsoft patch update, your CUDA builds appear to work fine, but some of your applications suddenly exhibit strange bugs. After many days of debugging, you find out that incorrect code is being generated.
How do we know these are not merely theoretical possibilities? Because people have gone in before and removed the version checks, and a good number of them ran into such issues.
As far as the version checks are in header files, you should feel free to modify or remove them as you see fit. Just be aware of the issues outlined above and keep in mind that you are now operating an unsupported tool chain.
Because of the tight integration of CUDA with the host toolchain (this was perceived as a valuable feature when CUDA was created) there are fairly intricate dependencies that are easily broken by host toolchain updates. The version checks ensure that the host toolchain has been validated to work properly with CUDA and any necessary adjustment on the CUDA side have been applied.
you say ‘good possibility of those two issues’. where do you have evidence for that? Its hypothetical at best. VS does not change sigificantly between updates for your tool chain.
whereas the current situation you are offering 100% failure to use the product.