Visual Studio can't build due to rc.exe

Question

Found this on Google... I would assume that in your case you would copy rc.exe and rcdll.dll to visual studio 2012\vc\bin or wherever you have it installed:

Part 2: FIX LINK : fatal error LNK1158: cannot run ‘rc.exe’

Add this to your PATH environment variables:

C:\Program Files (x86)\Windows Kits\8.0\bin\x86

Copy these files:

rc.exe
rcdll.dll

From

C:\Program Files (x86)\Windows Kits\8.0\bin\x86

To

C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin

Or I also found this:
Microsoft left a few things out of their MSVT package. Since no one knows whether they were left out by mistake or for license reasons, no one with MSVC is too interested in giving them out. A few Google searches turn up some tricky sources. Fortunately, Microsoft has finally wised up and solved this problem and many more.

http://msdn.microsoft.com/vstudio/express/support/faq/default.aspx#pricing

http://msdn.microsoft.com/vstudio/express/support/install/

A good amount of MSVT missing files are there but the missing SDK files aren't.

and this:
I had the same problem which I solved by doing this:

1. Installing the Microsoft .Net Framework 2.0
2. Adding the path of the .NET Framework files (for me "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727") to Global compiler settings > Programs > Additional Paths within Code::Blocks.

Now I can build and link resource files without errors.

We hit this issue with our CMake/Visual Studio 2015 builds after also installing VS2017 on the machine. The correct solution in our case is to specify the Window Kit version (8.1) to the Visual Studio Command Prompt - otherwise you get the Windows 10 Kit by default which doesn't include rc.exe in the bin directory.

e.g. Start Menu->Visual Studio 2015->VS2015 x64 Native Tools Command Prompt

%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" amd64 8.1

Note the 8.1 option on the end

From what I have found, if you have a windows 7 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 12.0\VC\bin and paste the two files you have copied into it.

I had the same problem, and the above posted solution did not work. My solution was derived from it, and it worked for me, if the ones above do not work you can give this one a try.

This rc.exe error can occur if the Visual C++ compiler and the Windows 10 SDK versions don't correspond to the same Visual Studio year. In general, the solution is to make sure you have on your system, and are using in the compilation, VC++ and Windows SDK for the visual studio year you are using.

For instance, if you have Visual Studio 2017 or 2019, and you installed Build Tools 2015 without selecting to install its own 2015 Windows SDK (default installation does not install it!), and are trying to use it to compile, you may run into this problem.

In my case, I already had Visual Studio 2017. When I tried to use Build Tools 2015 to compile a python library (or probably any program), this same 'rc.exe' error occurred. I read that the VS2015 14.0 C++ compiler can glitch if it tries to use the Windows 10 SDK from Visual Studio 2017.

I uninstalled Build Tools 2015, and reinstalled it, this time as a custom installation, selecting to install both visual C++ and Windows 10 SDK components. This fixed the issue.

UPDATE: I just looked at Build Tools 2015 again, and apparently there is no custom installation option anymore. If so, installing Visual Studio 2015 with C++ and Windows SDK components should also work. Edit: commenter has found the customizable build tools installer

In my case, I had a mix and match error between projects created in VS2015 and VS2017. In my .vcxproj file, there's this section called PropertyGroup Label="Globals">. I had a section for TargetPlatformVersion=10.0.15063.0. When I removed the TargetPlatformVersion, that solved the problem.

Sorry I can't copy and paste the block here, but stackoverflows coding format did not allow that.