I need to use C::B with a recent version of MS VC++ compiler like the ones in VS2015 or VS2017, and eventually future ones, but C::B does not offer such option. The most recent VC++ version that C::B allows the user to choose from its list, in the Settings, is VC++2010 (MSVC++10.0) wich is quite old. After some search I didn't find an explanation to overcome the problem. Not even C::B site offers a solution. How can I do that?
After some attempts I made with C::B settings and VC++ compilers, I found a solution that is not complicate at all. In this post I will show how to use the latest versions of VC++ compiler (MSVC++ 14.0 or higher) with CodeBlocks - with no need to install Visual Studio. The solution would be identical if you prefer to use Visual Studio instead.
I will answer the question for 32 and 64 bits projects. By default it will support std C++14.
Content:
A) Install the latest version and compile for x86 projects;
B) Change to C::B 64bits projects.
A) Install and use for 32bits projects
Install the latest version of VC++ compiler.
The VC++ Toolset can be obtained through NuGet.
To get NuGet look here: NuGet.
Run the following command from the command line. The command installs the latest version is (according MSDN):
c:\\> nuget install VisualCppTools.Community.Daily.VS2017Layout -Version 14.14.26423-Pre -Source https://visualcpp.myget.org/F/dailymsvc/api/v3/index.json
Install Microsoft Build Tools 2015 (or higher). Here I will stick with 2015, but you can go for 2017.
For 2015 the installer is here BuildTools2015. Run it to install the tools.
Open C::B and configure it. C::B last version for Microsoft Visual C++ is 2010. We can use it, but seting a more recent compiler.
3.1 Go to Settings>>Compiler
3.2 In "Selected Compiler" select MS visual C++ 2010. This is the higher version available in C::B.
3.3 Select the Tab "Toolchain executables" and set the Compiler's directory with the directory with the VC++ Toolset. In my case:
D:\VisualCppTools.14.0.25114-Pre\lib\native
Confirm if the "Program Files" boxes of the tab are filled.
3.3 Select "Search directories" tab.
3.3.1 In "Compiler" tab add the include directory path.
In my case is:
D:\VisualCppTools.14.0.25114-Pre\lib\native\include
Possibly the following will also be needed (from Build Tools).
C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt
Also if not already there and if needed (in my case)
C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um
3.3.2 In "Linker" tab enter the paths for the libs. In my case.
D:\VisualCppTools.14.0.25114-Pre\lib\native\lib
Possibly, also,
C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10240.0\ucrt\x86
And if your project complains about uuid.lib, then insert also (in my case),
C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86
3.3.3 "Resource compiler" tab. This is optional. In my case,
D:\VisualCppTools.14.0.25114-Pre\lib\native\include
And that's it! But if we prefer, C::B allow us to change the compiler name.
B) Change the C::B project settings for x64 projects
Point linker libraries' paths to their x64 counterparts. In the Settings menu choose "Search Directories">>"Linker".
1.1 For the compiler library, add "amd64". In my case:
D:\VisualCppTools.14.0.25114-Pre\lib\native\lib\amd64
1.2 For "ucrt" and "um" add "\x64" to the paths. Example for my case:
C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10240.0\ucrt\x64
C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x64
For the compiler select the Tab "Toolchain executables" and insert the prefix "amd64\" for C++ compiler and Make program, as: amd64\cl.exe, amd64\nmake.exe
Again, that's it!
Good work!
Below are compiler options entries for MSVC 2015 installation on Windows 7 when compiling a "plain" C++ console application (no CLI) for a x86 target machine:
INCLUDE=
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\atlmfc\include
C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt
C:\Program Files (x86)\Windows Kits\8.1\Include\um
C:\Program Files (x86)\Windows Kits\8.1\Include\shared
C:\Program Files (x86)\Windows Kits\8.1\Include\winrt
LIB [x86]=
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\atlmfc\lib
C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\ucrt\x86
C:\Program Files (x86)\Windows Kits\8.1\lib\winv6.3\um\x86
C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\Lib\um\x86
LIBPATH=
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\atlmfc\lib
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib
I added INCLUDE and LIB to search directories for compiler and linker, respectively, and everything worked in C::B for a x86 console application.
I didn't experiment with x64 architecture...
I've searched online and couldn't find anything that resembled to my issue.
I created an empty C++ project and added a main.cpp with a return and I can't get it to build. Here is the message I receive :
1>------ Build started: Project: Project1, Configuration: Debug Win32 ------
1>LINK : fatal error LNK1158: cannot run 'rc.exe'
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Is there somewhere within VS2012 where I can specify where to find this executable? I have installed the Windows 7 SDK and I have this executable at:
C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin
I come from Code::Blocks and using mingw-gcc without any trouble, but lately I've been needing VS for managed implementations so I hope someone has an idea.
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:
Installing the Microsoft .Net Framework 2.0
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.
In my case, VS 2019 on Windows 10 x64,
I followed mostly what it was said in the answers but pasted rc.exe and rcdll.dll from C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x86 to C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin, which is where link.exe is.
I'm on Windows 7 x64 and Visual Studio 2017. I get this error trying to compile a cython script.
That's how I solved:
I copied and pasted rc.exe and rcdll.dll from:
C:\Program Files (x86)\Windows Kits\8.1\bin\x86
to
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64
Here is my almost similar case:
I have VC2010 working project under Win7 32bit. I make clean install of VC2013 under Win8.1 64bit
After successful converting of my project from VC2010 to VC2013, during 1st compilation the following error rise:
Finished generating code
LINK : fatal error LNK1158: cannot run 'rc.exe'
Solution 1:
Delete whole line “<ExecutablePath Condition=”...”>...</ExecutablePath>” in element “<PropertyGroup>” in NameOfYourSolution.vcxproj file in notepad before to run VC2013
Solution 2:
Copy only two files: rc.exe and rcdll.dll from “c:\Program Files (x86)\Windows Kits\8.1\bin\x86\” to “c:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\” and compilation will be successful!!
Note:
a)It is not need to touch any PATH or other Windows or VC environment variables.
b)“Platform Toolset” (Project Property Pages –> Configuration Properties –> General) will be automatic set to “Visual Studio 2013 (v120)” (not change it to “Visual Studio 2010” to be able to continue to develop your project under VC2013 concepts)
In my case the error was due to a bad setting in a vcxproj. The vcxproj was from a third party, so I'm not sure how it got in that state.
Specifically, for one of the platform/profile combos, the platform folder was missing from the Windows SDK bin folder:
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<ExecutablePath>$(VCInstallDir)bin\x86_amd64;$(VCInstallDir)bin;$(WindowsSdkDir)bin\NETFX 4.0 Tools;$(WindowsSdkDir)bin\x86;
is correct, where
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<ExecutablePath>$(VCInstallDir)bin\x86_amd64;$(VCInstallDir)bin;$(WindowsSdkDir)bin\NETFX 4.0 Tools;$(WindowsSdkDir)bin;
was incorrect. Might need to scroll to the end of the code boxes to see the difference.
Note also, that for some strange reason $(WindowsSdkDir)bin\x64; did NOT work for me. Tried to figure out why, when rc.exe definitely exists in that folder, but I gave up.
In my opinion, the solutions from previous posters that involve copying rc.exe all over the place are wrong, because your project will not work on anyone else's machine. If you fix up the paths in the project correctly, it should work on any machine with a correct installation of the Windows SDK.
I'm on Windows 10 x64 and Visual Studio 2017. I copied and pasted rc.exe and rcdll.dll from:
C:\Program Files (x86)\Windows Kits\8.1\bin\x86
to
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64
it's works with: ( qt creator 5.7.1)
This might be a little outdated. But if copying the rc.exe and exdll.dll did not work, there is a chance that the windows sdk is not installed properly even if the windows sdk folder exists. You can update the sdk for win 8 in the following page:
http://msdn.microsoft.com/en-US/windows/hardware/hh852363
After re-installing the sdk, the problem would get solved. Also make sure that platform toolset is set properly.
I've encountered this issue recently. I have both VS 2015 and VS 2017 installed, Windows kits 8.1 and 10 installed.
Command prompt from VS 2017 works as expected, rc.exe is visible. In VS 2015 this is not true.
Actually, vcvarsall.bat script from VS 2015 does add a path to Windows 10 kit to PATH variable, but it adds a slightly wrong path. It adds path to
"C:\Program Files (x86)\Windows Kits\10\bin\x86"
while the actual path is
"C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x86"
It seems that updating Windows 10 kit (or installing VS 2017) led to this issue.
So the solution is simple: just create symbolic links in "C:\Program Files (x86)\Windows Kits\10\bin" folder pointing to the corresponding folders in the underlying folder, e.g. a symbolic link "x86" for folder "10.0.17763.0\x86", "x64" for "10.0.17763.0\x64" etc.
I'm on Windows 10 Pro x64, VS 19..
When trying to install mod_wsgi for apache in cmd.
C:\>python -m pip install mod_wsgi
This is the error I was getting from my command prompt.
LINK : fatal error LNK1158: cannot run 'rc.exe'
error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\BIN\\x86_amd64\\link.exe' failed with exit status 1158
I had to copy rc.exe & rcdll.dll from
C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x86
and add it to
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64
result from cmd
C:\>python -m pip install mod_wsgi
Collecting mod_wsgi
Using cached mod_wsgi-4.7.1.tar.gz (498 kB)
Installing collected packages: mod-wsgi
Running setup.py install for mod-wsgi ... done
Successfully installed mod-wsgi-4.7.1
Hope this helps someone.
I had the same problem on VS 2013 and was able to fix it by changing the Platform Toolset.
You can find it in project settings, general.
E.g. switching Platform Toolset to VS 2010 will cause VS to use the Windows\v7.0A SDK.
You can check which SDK path is used by adding this to your prebuild event:
echo using SDK $(WindowsSdkDir)
I'm using Windows 7 with VS 2013 (Update 3) and Intel Parallel Studio XE Composer Edition for Fortran Windows (Update 5). Out of the box I had the same issue.
Once I fixed the missing rc.exe problem I had another issue. The linker was missing kernel32.lib.
I corrected both issues by updating the Intel Composer Options (TOOLS->Options...->Intel Composer XE->Visual Fortran->Compilers).
For the Win32 tab I added:
Executables: C:\Program Files (x86)\Windows Kits\8.0\bin\x86; (just before $(PATH))
Libraries: C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x86; (at the end)
For the x64 tab I added:
Executables: C:\Program Files (x86)\Windows Kits\8.0\bin\x64; (just before $(PATH))
Libraries: C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64; (at the end)
Update...
I was also missing some SDK header files (winver.h and winapifamily.h). I added the following to the same TOOLS->Options... area.
For both the win32 and x64 tabs
Includes: C:\Program Files (x86)\Windows Kits\8.0\Include\um;C:\Program Files (x86)\Windows Kits\8.0\Include\shared;
I just figured out one (out of the 3 in total) projects in my VS2010 (SDK7.1) solution (projects are linked in a sequential linear dependency chain), had a .rc file in the project files that was empty.
Removing the empty .rc file (from the project, without deleting it) solved the "fatal error LNK1158: ... cvtres.exe" problem.
Update: The following copy fixed the problem:
xcopy "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\cvtres.exe" "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\x86_amd64\"
This will enable WinSDK7.1, via MSBuild, to be able to compile .rc files into the executables.
This is even easier than that with Visual Studio 2017. Follow these instructions: https://learn.microsoft.com/en-us/visualstudio/install/modify-visual-studio to modify using Microsoft Visual Studio Installer.
Once inside the Microsoft Visual Studio Installer, click modify under your installed Visual Studio package, make sure the Desktop development with C++ is checked, and the MFC and ATl support (x86 and x64), under summary.
This can be caused by a vcxproj that originated in previous versions of Visual Studio OR changing the Platform Toolset in Configuration Properties -> General.
If so, possible Solution:
1) Go to Configuration Properties -> VC++ Directories
2) Select drop down for Executable Directories
3) Select "Inherit from parent or Project Defaults"
Add to your environment variable window sdk 8.1 path
C:\Program Files (x86)\Windows Kits\8.1\bin\x64
then open Visual studio x64 Native tools command prompt and enter
vcvarsall.bat
If you really need to use the SDK Windows 10 with Visual Studio 2015, you have to download an older version on sdk-archive. Newer version of the SDK changed the place of the rc executable and MSBuild of Visual Studio 2015 update 3 (latest version) can't locate it.
At least the version 10.0.14393.795 of the SDK Windows is still compatible with Visual Studio 2015.
Maybe project file was touched by VS2017. Then when you link the project in 2015 "LINK : fatal error LNK1158: cannot run 'rc.exe'" can brake the build.
In vcxproj try to:
1) replace:
<WindowsTargetPlatformVersion>10.0.17763.0</WindowsTargetPlatformVersion>
with:
<WindowsTargetPlatformVersion>8.1</WindowsTargetPlatformVersion>
2) remove:
<VCProjectVersion>15.0</VCProjectVersion>
3) replace:
<PlatformToolset>v141</PlatformToolset>
with:
<PlatformToolset>v140</PlatformToolset>
I got the OP's link error about rc.exe when trying to execute pip install inside a bash task within an Azure DevOps pipeline that I was using to build a Python package from source with C++ extensions. I was able to resolve it by adding the path to rc.exe inside the bash task just before calling pip install, like so:
PATH="/c/Program Files (x86)/Windows Kits/10/bin/10.0.18362.0/x64":$PATH
That was inside an Azure job that was using vmImage: 'windows-2019' for its agent; i.e., Windows Server 2019 with Visual Studio 2019.
I was able to make it work for me also this way in windows
Set your environment variable to point to the location of your rc.exe
assuming you're using x86 version
C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x86
You can easily set your environment variable using
C:> setx path "%path%;C:\Program Files (x86)\Windows
Kits\10\bin\10.0.18362.0\x86"
Restart your Qt Creator
Clean and Rebuild
My answer to this quesiton.
Modify file C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\vcvarsqueryregistry.bat
The content of :GetWin10SdkDir
From
#REM ---------------------------------------------------------------------------
:GetWin10SdkDir
#call :GetWin10SdkDirHelper HKLM\SOFTWARE\Wow6432Node > nul 2>&1
#if errorlevel 1 call :GetWin10SdkDirHelper HKCU\SOFTWARE\Wow6432Node > nul 2>&1
#if errorlevel 1 call :GetWin10SdkDirHelper HKLM\SOFTWARE > nul 2>&1
#if errorlevel 1 call :GetWin10SdkDirHelper HKCU\SOFTWARE > nul 2>&1
#if errorlevel 1 exit /B 1
#exit /B 0
to
#REM ---------------------------------------------------------------------------
:GetWin10SdkDir
#call :GetWin10SdkDirHelper HKLM\SOFTWARE\Wow6432Node > nul 2>&1
#if errorlevel 1 call :GetWin10SdkDirHelper HKCU\SOFTWARE\Wow6432Node > nul 2>&1
#if errorlevel 1 call :GetWin10SdkDirHelper HKLM\SOFTWARE > nul 2>&1
#if errorlevel 1 call :GetWin10SdkDirHelper HKCU\SOFTWARE > nul 2>&1
#if errorlevel 1 exit /B 1
#setlocal enableDelayedExpansion
set HostArch=x86
if "%PROCESSOR_ARCHITECTURE%"=="AMD64" ( set "HostArch=x64" )
if "%PROCESSOR_ARCHITECTURE%"=="EM64T" ( set "HostArch=x64" )
if "%PROCESSOR_ARCHITECTURE%"=="ARM64" ( set "HostArch=arm64" )
if "%PROCESSOR_ARCHITECTURE%"=="arm" ( set "HostArch=arm" )
#endlocal & set PATH=%WindowsSdkDir%bin\%WindowsSDKVersion%%HostArch%;%PATH%
#exit /B 0
Modify this single place will enable the support for all Windows 10 sdk along with all
build target of visual studio, including
VS2015 x64 ARM Cross Tools Command Prompt
VS2015 x64 Native Tools Command Prompt
VS2015 x64 x86 Cross Tools Command Prompt
VS2015 x86 ARM Cross Tools Command Prompt
VS2015 x86 Native Tools Command Prompt
VS2015 x86 x64 Cross Tools Command Prompt
They are all working.
In my case, I installed the Windows SDK 10586 via Visual Studio 2015 -> Modify, then the following paths are installed.
C:\Program Files (x86)\Windows Kits\10\bin\arm64\rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\x64\rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\x86\rc.exe
For Visual Studio Community 2019, copying the files in the answers above (rc.exe
rcdll.dll) to C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\bin\Hostx86\x86 did the trick for me.
"Error LNK1158 cannot run 'rc.exe" could be resulted from your project was opened by newer MS VS version. For instance, your project was created in VS 2015, then later was opened by 2017. Then later your project is opened in 2015.
To resolve this issue, open yourProjectName.vcxproj, look for WindowsTargetPlatformVersion, and change to the correct VS version
For VS 2015, it should be 8.1
for VS 2017, it should be 10.0.17763.0
There are a lot of answers here, but I didn't see this one, which I believe is the right way to fix this Visual Studio bug. I recently had to install Visual Studio 2015 on a system that already had Visual Studio 2017 and 2019 along with multiple versions of the Windows SDK. When building either x86 or x64/debug or release, it could not find RC.EXE. The reason is that the Project's executable path (the $(VS_ExecutablePath)) value is incorrect. For x86 and x64, it's set to
C:\Program Files (x86)\Windows Kits\10\bin\x86
C:\Program Files (x86)\Windows Kits\10\bin\x64
which appears to be correct if 10 is replaced by 8.1 but I want to use the Windows 10 SDK not the Windows 8.1 SDK.
The Windows 10 SDK executables are actually in these directories (i.e. these are the SDKs I have installed right now):
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\arm64\rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64\rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x86\rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\arm64\rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64\rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x86\rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\arm64\rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64\rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x86\rc.exe
C:\Program Files (x86)\Windows Kits\8.1\bin\x64\rc.exe
C:\Program Files (x86)\Windows Kits\8.1\bin\x86\rc.exe
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin\RC.Exe
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin\x64\RC.Exe
In Windows 10 SDKs, the TargetPlatformVersion is part of the path, which allows the SDK executables/include/libs to be updated for each new TargetPlatform as it's released.
Choosing an RC.EXE and copying it to a directory in the path would work but each TargetPlatformVersion SDK directory has a different RC.EXE, so you might not know which one you are using -- especially if you have multiple developers and build machines. It's best to fix it in the projects.
To fix this,
Select all of the affected projects with Shift-Click
Right-click a selected project and select Properties,
Select VC++ Directories on the left
Select Executable Directories
Click the pull-down at the far right and select Edit.
Double-click the top blank line and for x86/win32 projects, add this to both Debug and Release configurations:
$(WindowsSdkDir)bin\$(TargetPlatformVersion)\x86\
For x64 projects, add this to both Debug and Release configurations:
$(WindowsSdkDir)bin\$(TargetPlatformVersion)\x64\
Leave "Inherit from parent or project defaults" checked. The "Evaluated Value" window may appear garbled but it seems to get fixed once you save and close the property pages.
I did not have to update "Library Directories" nor "Include Directories" but they might require similar changes.
This will make a number of entries in each Visual Studio project file that look like this:
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
<ExecutablePath>$(WindowsSdkDir_10)bin\$(TargetPlatformVersion)\x86\;$(ExecutablePath)</ExecutablePath>
</PropertyGroup>
The right way to fix this is by editing the property sheet for Microsoft.Cpp.Win32.user or to define your own property sheet to add this value to the inherited values, but the Visual Studio 2015 property manager seems to be buggy (2017/2019 is much better) so I found it best to just put the value directly into the projects. This also means every other developer or build machine that uses these projects will be able to build, as long as the chosen Windows 10 SDK is installed.
I've uninstalled VS11 using the the windows installer, and deleted just about every registry key I could find relating to it, but it still pops up with this when I try to reinstall it:
And I can't click the "..." or edit the path. Right-clicking does nothing either.
What do I have to destroy to change the install directory?
Still happening in official release:
I had the same problem though instead of forcing me to install into "c:\program Files" it forced me to install to the directory which I used for the Visual Studio RC. After using Process Monitor and the setup's logfile I was able to find a registry key that needed to be deleted.
The key was located at
HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-21-776561741-789336058-725345543-318838\Components\31F687BD8A467D54C830E018D99F7F3B
The SID will most likely be different for other systems yet you might be able to find the last string (31F687BD8A467D54C830E018D99F7F3B)
In order to find the key I did the following:
Downloaded ProcessMonitor from Sysinternals
Started Processmonitor with filter
Image Path ends with vs_premium.exe
Started vs_premium.exe
Closed the setup
Waited until Processmonitor didn't fetch anymore events
Opened the newest dd_vs_premium_.log file from %TEMP%
Searched for something and found
Condition 'VS_Install_path_KeyExists' evaluated to false. (i guess it will evaluate to true on affected systems. I tried this on a clean windows installation)
One line above it said
Registry key not found. Key =
'SOFTWARE\Microsoft\VisualStudio\SxS\VS7'
Searched for
Microsoft\VisualStudio\SxS\VS7
in Processmonitor
A few lines down ProcessMonitor shows me the key I had to delete
A simpler approach worked for me:
1 - Run the installer from the command line, with /uninstall /force switches, as in:
c:\vs_professional_ENU.exe /uninstall /force
2 - Re-run the installer normally.
I did this with VS2015 under Windows 10. Reference link.
The only solution I've found is on Windows 7 to create a hard Junction link to the directory your wanting Visual Studio installed to.
For Example, My SSD drive is not my boot drive and has a drive letter of B:.
I run the following command line
mklink /J "C:\Program Files (x86)\Microsoft Visual Studio 11.0" "B:\Program Files (x86)\Microsoft Visual Studio 11.0"
To the installer and Windows it thinks it installed it to the Program Files x86 directory on C: drive when it really installed it to the Program Files x86 folder on B: drive.
Here's a link to page about creating Junction links in Windows Vista and 7. http://www.howtogeek.com/howto/windows-vista/using-symlinks-in-windows-vista/
I dont have the rep to comment on the post above. Although he is correct in the syntax of those command switches, the program is bugged, it doesnt work with selecting the CustomInstallPath. In fact, for me, it just decides to open about 50+ iterations of vs_ultimate.exe in the process list...
I will try the Hard Junction as mentioned above as I am sure that will work.
As a sidenote, if anyone is interested, you can use the switch that allows you to acquire the installation ahead of time by running vs_ultimate.exe /Layout X:\somefolder\
I did that last night and hopefully my installation will go quickly since i havea ll the info, however I think in order to force it to use the offline version, you have to run vs_ultimate.exe /noweb.
This page refers to all the switches: http://msdn.microsoft.com/en-us/library/e2h7fzkw(v=vs.110).aspx
The above pages notes that: /p CustomInstallPath "Installs all re-targetable packages in the directory that you specify." Thay may mean that silently, whatever it is able to install off of your root drive, it will, but its hard to be certain and I have limited space on my SSD.
Before I try the hard junction, I may also try the above and see what heppens, then uninstall it if need be. Will post results
Try launching the installer with the following option:
/p CustomInstallPath="[your_path]"
For example:
vs_ultimate.exe /p CustomInstallPath="C:\MyDirectory"
To see all options use the switch /?
For me the final visual studio 2012 wanted to install into the same path as the (uninstalled) beta. I deleted most of the stuff in HKLM that had an exact match for the setup directory (ending with a \ e.g. C:\VS11Beta\) and then the setup let me choose again.
Probably not a solution for the OP(M:\Program Files sounds too generic to delete), but perhaps for others with this problem.
I had previously installed the VS 2012 Test Controller. Uninstalling it allowed me to change the install path.
How to change Visual Studio 2012 install directory?
What do I have to destroy to change the install directory?
Answer: You can change the physical directory without the need to "destroy or change" the install directory. This is an alternative "think smarter not harder" solution proposal.
Here are the specific material details you need to continue to use your logical M:\Program Files directory and solve the physical where the files are stored problem.
It also serves the rest of the community well for cleaner more reproducible installs, less effort and risk when using Beta builds. Its less risk because it encapsulates every file in the beta install. Want to go from beta to RC, no problem, just don't mount the beta drives, use an off the shell registry cleaner and reinstall clean to fresh drives every time.
The process uses PGP disks which can be logged in and logged out of / backed up as needed.
Initially, it seemed as though it would be possible to create just two drives. not so.
- Drive #1 mounted as F:\ for f:\Program Files (x86)\Microsoft Visual Studio 11.0
This is where I told Visual Studio setup to install files to. And it does function as a mountable container for 2.7 Gigs of files.
Drive #2 mounted as a folder on "C:\Program Files (x86)\" "Microsoft Visual Studio 11.0"
The intended purpose of the mounted folder was to collect up the remainder of 5.5 Gigs of files.
The actual list of 33 created folders I had to move to additional PGP folders.
Here is the inclusive list of folders you can create before setup deploys files to them.
C:\Program Files\Microsoft SQL Server
C:\Program Files\Microsoft SQL Server Compact Edition
C:\Program Files\Application Verifier
C:\Program Files\MSBuild
C:\Program Files\Microsoft
C:\Program Files\IIS Express
C:\Program Files\IIS
C:\Program Files\Microsoft Visual Studio 11.0
C:\Program Files (x86)\IIS
C:\Program Files (x86)\IIS Express
C:\Program Files (x86)\Microsoft ASP.NET
C:\Program Files (x86)\Microsoft Help Viewer
C:\Program Files (x86)\Microsoft SDKs
C:\Program Files (x86)\Microsoft SQL Server
C:\Program Files (x86)\Microsoft SQL Server Compact Edition
C:\Program Files (x86)\Microsoft WCF Data Services
C:\Program Files (x86)\Microsoft Web Tools
C:\Program Files (x86)\MSBuild
C:\Program Files (x86)\NuGet
C:\Program Files (x86)\Windows Kits
C:\Program Files (x86)\Common Files\Merge Modules
C:\Program Files (x86)\Common Files\Microsoft
C:\Program Files (x86)\Common Files\microsoft shared\DevServer
C:\Program Files (x86)\Common Files\microsoft shared\MSDesigners8
C:\Program Files (x86)\Common Files\microsoft shared\MSEnv
C:\Program Files (x86)\Common Files\microsoft shared\MSI Tools
C:\Program Files (x86)\Common Files\microsoft shared\SQL Debugging
C:\Program Files (x86)\Common Files\microsoft shared\SQL Server Developer Tools
C:\Program Files (x86)\Common Files\microsoft shared\TextTemplating
C:\Program Files (x86)\Common Files\microsoft shared\Visual Database Tools
C:\Program Files (x86)\Common Files\microsoft shared\VS7Debug
C:\Program Files (x86)\Common Files\microsoft shared\WF
C:\Program Files (x86)\Common Files\microsoft shared\Windows Simulator
This is perfect to prevent;
- Patch managers and patch management systems which inadvertently & unsupervised unmonitored, unaudited in willful ignorant bliss violate the premise of good promotion to production change control best practices
Developers who's code mostly works by random chance and really have no idea whats in the final product.
Hacker exploitation of the build environment.
Could have used True Crypt or PGP desktop. Just not whole disk encryption, have to be able to mount and unmount the resources.
I appreciate the hard junction approach, but unless you Safely ejecting & power off drives, it offers little process compliance and is neither safe or reliable as compared to safe PGP un-mounting/mounting. Developers will just power on the drives and make changes.
Regarding level of efforts to backup and restore, Backing up PGP drives as compared to hard junctioned drives is a wash about the same level of effort. But the value in not having to remember which folders are junctioned, which might need restored to restore a dev environment favors the fewer number of .PGD drives which contain all the needed folders ( ie do the remembering for you as a part of their function)
Consider this as an environment for when requirements are for mandatory non discretionary absolute auditable surety for a reproducible secure build. To meet that core objective, it has to be available only when its actually "needed" and has to be secured when its not needed.
Look into your installed programs and see if an instance of Visual Studio is already installed if so delete it and re-run the set up.
For this who still looking for a solution, What I tried and learned from this issue is that while "normal" (from control Panel) uninstall not every signatures of VS is not getting removed. So we have force uninstall from command line to remove all VS footprints. I have found the following answer in stack overflow very useful for me.
Run installer in command line (Admin) with argument:
vs_community_ENU.exe /uninstall /force
Then:
run vs_community_ENU.exe (or professional/enterprise).
How to install Visual Studio 2015 on a different drive