@xnode: To avoid misunderstandings, please note that my presence in these forums is not part of any kind of professional activity. I am just a hobbyist CUDA user at this point.
My statement addressed the poster’s issue directly, and you added useful detail. Personally, I use a very old version of MSVS (2010) so I am not familiar with the toolset selection menu item you mention, but I assumed (maybe incorrectly) that MSVS 2017 users know how to operate the GUI IDE to select a tool chain version supported by CUDA.
[Later:] For those who object to my advice “Use a supported CUDA” version, let me explain why I believe that this is the only responsible advice.
Early in the genesis of CUDA (2005-2006) a decision was made that CUDA should integrate into the most popular host tool chains as seamlessly as possible to create as little of a hurdle to adoption as possible. This tight integration creates dependencies of host header files for example. This was not deemed a particularly risky approach at the time, because in the early days of CUDA, when the ecosystem was tiny, new CUDA releases were shipped every four to five months on average, while host tool chains had new releases every one to two years.
Tight integration with the host tool chain means that adjustments must be made to CUDA to adapt to new versions of the host tool chain. The integration must then be validated, using a large-ish body of CUDA code. In case of problems with the CUDA tool chain, NVIDIA offers support only when CUDA is used with such a validated, a.k.a. supported, host tool chain. Version checks in header files, such as the one identified by the OP enforce the use of a supported tool chain.
In the cited version check from CUDA 9, it is clear that only MSC version up to and including 1911 are supported, while the latest MSVS update identifies as version 1912. The discussions of such issues in these forums tend to follow a predictable trajectory: Someone will suggest a “workaround” that consists in modifying or eliminating the version check. That then seems to work for trivial code, but the next thing that typically happens is that the compilation for more complex code results in “strange error messages” (a consequence of missing adjustments). Some really clever people will then propose various hacks to CUDA header files, and this then seems to eliminate the compilation bugs.
The problem with that: this is hackery, not a reliable fix. Things may seem to work but may silently compile into an incorrect binary. There is no validation of the changes because CUDA programmers don’t normally have the large body of code at their disposal that NVIDIA uses for validation. It also effectively creates a one-off branch of the CUDA tool chain that makes support impossible should other problems occur later on. I highly doubt that NVIDIA accepts bug reports that state: “I am using CUDA version N, except for the following modified header files you will find attached to the bug report.” As I said, that is a guess, but it is an educated one.
The scheme of CUDA requiring specific host tool chains has lead to an increasing number of version mismatch issues as in this thread (on all OS platforms) as the cadence of CUDA releases has slowed down, while the cadence of host tool chain releases has increased rapidly.
[speculation] Why not have rapid-fire CUDA releases to deal with the issue? Plausible approach, but would likely drive up development costs. How would NVIDIA recoup that cost when the entire CUDA ecosystem is provided free of charge? Last time I purchased the equivalent ecosystem for my CPU (which also has a MSVS integration challenge), it set me back around $2K, so I have a pretty good idea how that vendor recoups (at least a part of) their cost.
Before someone points out that additional cost could be recouped through hardware sales, keep in mind that the bulk of GPU sales is still GeForce, and that in the consumer market the additional money NVIDIA can charge for providing CUDA is approximately $0. The price in that market is pretty much determined by how GeForce competes against the competition in popular games (I think any secondary pricing effects from crypto currency mining will be temporary).[/speculation]