Opening a folder in Visual Studio from command prompt - visual-studio-2017

I see demos where a folder with an angular app is opened in visual studio code using
code .
from the terminal.
Could I do the same with Visual Studio. Perhaps I should write Powershell Scripts to accomplish the same?

I was able to open a folder from command line using the following in VS 2017
devenv.exe /Edit <path to folder>

Locate the .exe file of the IDE environment (should be found in the IDE folder in the directory on which VS 2017 was installed). On my system, the exact path for the .exe file is:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE
Yours might differ, but you should be able to find it. If not, just use the windows search feature to look for devenv.exe.
Once you've located the directory on which devenv.exe resides, proceed to add the path of that directory to your PATH environment variable. There are 3 ways to do that. The easiest way is to use the Windows GUI-based environment editor. Or you could use a third party environment editor (I recommend RapidEE). Another way is to do it directly from the command prompt.
And that's basically it. You're good to go. So let's say you have a directory containing all your source codes and header files at C:\DevFiles. Now, you can just launch your command prompt and from there either cd to C:\DevFiles and then type devenv . OR you can straight away type devenv C:\DevFiles

I think this is currently not possible.
The first requirement is to be able to start Visual Studio from the command line.
The equivalent of the “code” command is “devenv”. If you type this in your command line Visual Studio opens. Just ensure that the command is included in your path if you use a normal command prompt. It is already included in the path variable if you use the Visual Studio Command prompt.
The dot in the code . sets the current directory as working directory. If you are running < VS 2017 you are already out of luck now. In older version of Visual Studio it is not possible to work with such a folder approach. However, in Visual Studio 2017, you can open code from nearly any type of directory-based project into Visual Studio without the need for a solution or project file.
This could all be so easy now if only it would possible to pass this information to the devenv command.
However this is not the case: https://learn.microsoft.com/en-us/visualstudio/ide/reference/devenv-command-line-switches
Thus you would have to find another way to make Visual Studio 2017 in effect do something like File > Open > Folder and set the current directory as working folder.
This might be possible if you write a Visual Studio extension and hook up on the connected event.
But in essence the answer to your question is “not possible at the moment.”

The OP has been answered already and my answer only expounds on what has been said. The BLUF is <pathToVS>devenv.exe /Edit <pathToFolder> or <path to VS>devenv.exe <path to folder>
I am forced to use VS2017, VS2019, and VS2022.
I added the path to my environment vars and had consistent success where using the full path in a literal would fail.
Since I work primarily from PowerShell I made this function for my needs. This uses the associated version of visual studio by invoking the solution [.sln] file. My .sln files are associated with the 'Microsoft Visual Studio Version Selector' If you only have one VS installed it still works as your sln files [should] be associated with your VS.
function Open-Solution {
<#
.SYNOPSIS
Open solution file for visual studio
.DESCRIPTION
Open proper version of visual studio
-RootDirectory
folder to search for solution in or to open in VS
<Usage>
PS C:\>sln
- Open folder or solution in the active directory
PS C:\>sln .\myApp
- Open folder or solution in the .\myApp directory passed in the parameter
PS C:\>sln -path .\myApp
- Open folder or solution in the .\myApp directory passed in the parameter
#>
[Alias('sln')]
param (
[Alias('path')]
[Alias('searchpath')]
[string]$RootDirectory = $PWD
)
$solutions = Get-ChildItem -Recurse -Path $RootDirectory -Filter "*.sln"
if ($solutions.Count -eq 1) {
Invoke-Item $solutions.FullName
} elseif ($solutions.Count -eq 0) {
$Yes = New-Object System.Management.Automation.Host.ChoiceDescription '&Yes, Open current folder', "Open [$RootDirectory] in VS";
$No = New-Object System.Management.Automation.Host.ChoiceDescription '&No', "Do Not Open [$RootDirectory]";
$options = [System.Management.Automation.Host.ChoiceDescription[]]($Yes, $No);
$title = "No solution files found searching [$RootDirectory]`n`n";
$message = "Would you like to open $RootDirectory in Visual Studio?";
$result = $host.ui.PromptForChoice($title, $message, $options, 1);
switch ($result)
{
0
{
Write-Host Opening [$RootDirectory] in VS -ForegroundColor green;
Invoke-Command {devenv.exe $RootDirectory };
break;
}
1
{
break;
}
default
{
break;
}
}
} elseif ($solutions.Count -gt 1) {
#TODO: allow selection deal with subfolders. (Doubt juice worth squeeze)
Write-Host "`nI found more than 1 solution. Which one do you want to open?" -ForegroundColor Yellow;
$solutions | Format-Table #{ Label="Solutions"; Expression={" --> $_"} }
}
}
I hope this adds value to your work stream.
Cheers

I don't know if this could be helpful but this might be the way to open a folder in visual studio.
go to the directory you want to open in visual studio in cmd/terminal
type explorer .
it will open the same directory in the file explorer
then right click and choose open with visual studio

This is what I do as a shortcut:
Navigate to the folder, ex. "c:\project".
Click on the navigation bar, as you would change location. Then type "cmd"
CMD will prompt to this directory
Type "code .", hit enter.
VBS should now load project folder.

In windows command line navigate to your project folder and type this command:
devenv start .

Related

MSBUuild is looking for "...\v4.0\V110\Microsoft.Cpp.Default.props" when we have ".../\v4.0\V140\Microsoft.Cpp.Default.props"

While building the project "Common.vcxproj", We are getting Error message : error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
The machine has the tool installed at "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.Cpp.Default.props" , but the .vcxproj is looking for "V110" folder.
In the Project file ""
and We have registry key = "VCTargetsPath" and value = $([MSBuild]::ValueOrDefault('$(VCTargetsPath)','$(MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\V140\'))
Question is why the MSBUuild is looking for "...\v4.0\V110\Microsoft.Cpp.Default.props" when we have ".../\v4.0\V140\Microsoft.Cpp.Default.props"?
Thanks
Question is why the MSBUuild is looking for
"...\v4.0\V110\Microsoft.Cpp.Default.props" when we have
".../\v4.0\V140\Microsoft.Cpp.Default.props"?
Please try these:
1) please check register editor and enter both HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSBuild\ToolsVersions\14.0 and HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0 and then make sure that it uses v140's path as this link shows.
2) Right-click on your project in VS 2015 IDE-->Properties-->Configuration Properties-->General-->change Platform Toolset to v140.
3) Also, check whether you define any VCTargetPath under Project Properties(right-click on your project)-->xxxxx-->Command Line
4) Run npm install -g --production windows-build-tools in Powershell as administrator
5) If these does not work, please go back to step one, and then change VCTargetsPath to C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\ directly.
Or run [Environment]::SetEnvironmentVariable("VCTargetsPath", "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140", "Machine") in powershell.
Hope these could help you.

c1010070: Failed to load and parse the manifest

I have an existing wxWidgets project which I am trying to compile under Visual Studio 2010 (the project was created probably with older version of Visual Studio - could be even VS2003). I compiled wxWidgets library (also included paths in my project). When compiling my project now, I get this error:
1>------ Build started: Project: Terminals, Configuration: Debug Win32 ------
1>Build started 8/24/2015 10:56:23 AM.
1>InitializeBuildStatus:
1> Touching "Debug\Terminals.unsuccessfulbuild".
1>ClCompile:
1> All outputs are up-to-date.
1>ResourceCompile:
1> All outputs are up-to-date.
1>ManifestResourceCompile:
1> All outputs are up-to-date.
1>Link:
1> All outputs are up-to-date.
1>Manifest:
1>
1>wx\msw\wx.manifest : general error c1010070: Failed to load and parse the manifest. The system cannot find the path specified.
1>
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:01.59
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Can someone help?
This happens if your project's path has a space in it, for example in my case the project is within my Windows account, so the path begins with "C:\Users\Adam Reece...". I then get "C:\Users\Adam" within a "cannot find" like error when building the manifest.
This is 100% a bug with Visual Studio recently of which Microsoft refuses to recognise. You are not in the wrong for having a space in your path as it's been supported since Windows 95. However as a workaround you either need to make sure there are no spaces in the full path to your project, or disable generation of the manifest. (Project properties -> Linker -> Manifest File -> Generate Manifest -> Change to No (/MANIFEST:NO).)
Based on your description, I suggest you to validate your manifest file and make sure it is correct. You can use Manifestchk.vbs or “ mt.exe -manifest 1.manifest -validate_manifest “.
Moreover, from your error message, you need make sure the complier can find your manifest file configure your configuration correctly.
Go to “Configuration Properties -> Linker -> Manifest File”; turn the
“Generate Manifest” to “No”.
Go to “Configuration Properties -> Manifest Tool “; add your manifest
file path, like: (give mainfest file name like “f:/xxxx.manifest”) to
“Additional Manifest Files”; and turn the “Embed Manifest” to “No”.
Eventually, rebuild again.
If you have any more questions, please feel free to let me know.
This error message always happen when Visual Studio could not find the file. There are some potential causes:
Numbers or spaces in the project name
Project name too long
Started creating the project from a blank project that doesn't have
all of the parts.
I'd suggest trying each of the following to see if it fixes the issue- but backup your project/solution directory first.
A) Clean and rebuild the solution
B) Right click on the solution for the project (in Solution Explorer) and rename the solution to a very simple name (e.g., soln). Then do the same for the project (e.g., rename to proj). Do a rebuild all and see if the problem goes away. If it does you can rename the solution and project to something more meaningful.
C) Right click on the project and open it's properties. Go To Link | Manifest and turn off use of the manifest. Rebuild.
D) Create a new Win32 console project. Have Visual Studio create the initial CPP and .H files you need. Open your old source files and copy the code from those into the new files. Rebuild the new project.
I had the same problem and found the solution that DOES NOT require creating a new user profile...
Yes, it is caused by spaces in usernames. But why? Because mt.exe uses TEMP/TMP environment variables. On one of my machines, the username was with the old 8.3 format in TEMP (C:\users\gerson~1) and that worked. This gave me a hint as to how to adress the problem:
set your users' TEMP to some folder that has no spaces
set your users' TMP to some folder that has no spaces
Ensure you restart VS so that the settings changes take effect. Your build should work now ;)
I had this error together with msb3073. I solved the issue by modifying the project's vcxproj file, changing from:
<PostBuildEvent>
<Command>mt.exe -manifest DesignedForWindows7.manifest -i [...]
</Command>
</PostBuildEvent>
to
<AfterBuildEvent>
<Command>mt.exe -manifest DesignedForWindows7.manifest -i [...]
</Command>
</AfterBuildEvent>
where, in place of [...], there is some command line code that I just copied-pasted.
Be careful that there might be more than one such code block in the vcxproj file
UPDATE 02/07/21: Found a solution for Win10.0..... SDK
https://stackoverflow.com/a/49276285/16360714
I got c1010070: Failed to load and parse the manifest
because my Windows User Profile had a space in it e.g. C:\Users\ John Doe\ and I was trying to use UE4 with C++ and Visual Studio 2017, Win 8.1 SDK
FINAL SOLUTION AT END
Solution 0: CHange TMP and TEMP Windows environment variables to folders with no space. This could break other programs. I kept it changed though while trying other solutions.
Solution 1: Exclude C\User\John Doe ... folders from the project
Solution 2: Try to change your Windows Profile Folder Name (tutorials on YouTube)
Solution 3: Create a new Windows local account with no whitespace and use it for dev
Solution 1 Explanation
If you are using UE4, Makefile will be your Project Configuration default. So you won't have access to Linker or Manifest Tool Settings.
I was getting the following errors when building:
Severity Code Description Project File Line Suppression State
Error c1010070 Failed to load and parse the manifest. The system cannot find the file specified. VirtuPilotv3 C:\Users\John
Severity Code Description Project File Line Suppression State
Error LNK1327 failure during running mt.exe VirtuPilotv3 K:\VRDEVELOPMENT\Virtu-Pilot\Intermediate\ProjectFiles\LINK 1
1
Severity Code Description Project File Line Suppression State
Error MSB3073 The command "K:\VRDEVELOPMENT\UE_4.26\Engine\Build\BatchFiles\Build.bat VirtuPilotv3Editor Win64 Development -Project="K:\VRDEVELOPMENT\Virtu-Pilot\VirtuPilotv3.uproject" -WaitMutex -FromMsBuild" exited with code 6. VirtuPilotv3 C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.MakeFile.Targets 44
I noticed the Macro $(PATH) in Property Page>General>Executable Directories contained a C:\ Users folder path "C:\Users\John Doe.dotnet\tools" to be specific.
So I added the .dotnet folder to my exclude directories and BINGO! I could build and open the editor. [1 VISUAL STUDIO WARNING]
Discovered C:\Users\John Doe.dotnet\tools is found under Windows "path"Environment Path Variables Image variable
I'll probably make a copy of the .dotnet folder to something like C:\VisualStudioCustom and add that folder as Windows Path New .dotnet folder set as path. This Should Solve the problem for all projects. As the new folder will automatically get added to Visual Studios Macro $(PATH). [IT ACTUALLY WORKED, NO VS ERRORS]

Pass file as an argument to visual studio

I try to debug a program in VS2010. In Windows PowerShell I type./Nbody.exe ./config.txt. But, when I enter .\config.txt or other forms of it in the Command Argument form Debugging section from Property Manager window it seems that my program cannot find the file. In fact this part of my code respond:
ifstream CSVfile(CSVFileName);
if (CSVfile == NULL) {
cout << "ERROR: Cannot Open CSV file" << endl;
exit(1);
}
Visual studio calcutates relative paths starting at working dir path. So, you have to use visual studio variables as $(ProjectDir) to compound the paths of your files.
Something like: $(ProjectDir)\config.txt, otherwise you have to set the path relative to working dir path.
Let's say your structure is this:
project_name
+ project_name
| project_name.sln
| debug
| project_name.exe
| config.txt
+ ipch
and you have .\project_name\project_name as working directory.
The path you enter in the project configuration for debugging has to be relative to the working dir:
..\debug\config.txt
Update
As #Goku states in his (I'm assuming Goku is a 'he', :) ) comment:
For VS2017, $(ProjectDir) already contained a '\' concatenated on the directory name.

'cmake' is not recognised as an internal or external command

I'm trying to run cmake in Visual Studio 10, for esys-particle-win.
My path to cmake:C:\Program Files (x86)\CMake 2.8\bin\cmake.exe
My path to esys-particle-win:C:\esys-particle-win\trunk\buildvs2010\mkvs10.bat
The commands I'm typing in the administrator command prompt of Visual Studio 2010 are:
cd c:\esys-particle-win\trunk\buildvs2010
mkvs10.bat
and I'm getting this error:
'cmake' is not recognized as an internal or external command
contents of mkvs10.bat:
cmake .. -G "Visual Studio 10" -G "NMake Makefiles"
could anyone tell me where I am wrong?. I don't know computer programming. I followed the instructions mentioned in section 2.3.1 of this site: `
https://launchpadlibrarian.net/139659869/esys-particle-win-%28v2.1%29-build-instructions.pdf
`
Any help would be greatly appreciated, Thank you.
The error message means it cannot find cmake.
You can add its location to your path from the prompt like this:
set PATH="C:\Program Files (x86)\CMake 2.8\bin\";%PATH%
As #doctorlove mentioned above, the error message means it cannont find Cmake.
Note that quotes aren't needed in PATH environmental variables on Windows. So the above example on Windows would look like:
set PATH=C:\Program Files (x86)\CMake 2.8\bin\;%PATH%
I had the same issue, and resolved it in this post.
note that if you installed cmake via chocolatey, you may have neglected to add the argument --installargs 'ADD_CMAKE_TO_PATH=System'. If you've already choco-installed cmake without that argument, re-installing via --force won't respect the new argument: you'll need to uninstall and then install. specifically choco install cmake --installargs 'ADD_CMAKE_TO_PATH=System'
I had the same problem since I intalled CMake in D:\Program Files , I fixed it by manually adding a path variable.
Open control panel
Go to System and Security then go to System.
How it looks like in after step 2
Here Select advanced System settings, a dialogue box will appear.
The dialogue box
Now go to Environment Variables.
Now select path and then click on edit
After the 4th Step
Here add a new path at the bottom of many pre existing paths.
In my case i installed CMake in D:\Program Files\
So I need to add path D:\Program Files\CMake\bin. You should copy the path to your CMake folder and add \bin at the end.
Now open you have to restart command prompt to see the changes.
I found the CMake to be:
C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin
I added it to the User PATH as described above, by hrithik singla, and node-gyp worked, specifically "npm install". I expect it will change again in the future. So the way I found it was by having Windows Explorer search "C:\Program Files (x86)\Microsoft Visual Studio\2019" and then dig through the results for the CMake path. Probably, other development tools will install CMake to different folders.
I'm trying to build a project with my recently downloaded Visual Studio Community 2017, but had no CMake on my path.
It did not help, even after I had gained VCVars: "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x64
Instead of separately installing a copy that might work with these answers, although I'm not sure it would have the generators I need(?), I found one in the installation directory, which had a different path than what was in the guide I was using.
Here is my invocation line: "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -G "Visual Studio 15 2017" -DCMAKE_BUILD_TYPE=%CMAKE_BUILD_TYPE% ..
There are a few issues that can cause this. And it's mostly windows related. This is more on the cmake side of things, but it addresses a few windows specific problems you may encounter using CMake with Windows. This is fresh in my head, and this popped up, so I'll drop this here. Here we go.
1. CMake will separate a variable to list if there are spaces in the path.
If you are calling another instance of CMake from within CMake, Sending a Program Files path will slice those strings, and divide your variable into a 3 item list. The spaces will be replace by a semicolon divider.
set(CMAKE_EXE C:\Program Files (x86)\CMake\bin\cmake.exe)
"C:\Program;Files;(x86)\CMake\bin\cmake.exe <- CMAKE_EXE is now a 3 item list separated by ; "
list(LENGTH ${CMAKE_EXE} count)
message("CMAKE_EXE has ${count} items") "-> displays 3"
On Windows, All path variables should be enclosed in quotations to infer that they are 1 single string variable. Not just for cmake, but for batch scripting, basic command line etc.
set(CMAKE_EXE "C:/Program Files (x86)/CMake/bin/cmake.exe")
Now, any time you reference CMAKE_EXE you'll need to always keep it enclosed in quotations, becuase cmake WILL break it to a list again otherwise.
execute_command(COMMAND cmd /c ${CMAKE_EXE} -P myScript.cmake) <-- BAD
execute_command(COMMAND cmd /c "${CMAKE_EXE}" -P myScript.cmake) <- GOOD
Just get in the habit of always putting quotations around paths you reference.
2. Stay away from the Windows back slashes!.
Windows uses back slashes by default for it's path divider, which are escape sequences in most coding languages, including CMake. Just send windows / forward slashes instead. This eliminates any headaches you'll have with doubling up escape characters in string literals to match the path. \
And remember, windows is always gonna try to give you paths in \ format. Windows likes backslashes in certain places like environment paths, and settings files, while cmake likes forward slashes. You need at some point to convert between the different formats.
Use something like this to convert the path to be more cross platform compatible. You can replace "in place" on your existing variable.
"CMAKE_EXE = C:\Program Files (x86)\CMake\bin\cmake.exe <- value before"
string(REPLACE "\\" "/" CMAKE_EXE "${CMAKE_EXE}") "<- notice the quotes again"
"CMAKE_EXE = C:/Program Files (x86)/CMake/bin/cmake.exe <- value after"
Take a look at these CMake functions designed to do path conversions.
https://cmake.org/cmake/help/latest/command/file.html#to-native-path
3. Sometimes, Windows interprets unquoted paths as 8.3SFN (8DOT3) format
8.3 filename
Back in the days of MSDOS and Windows 95, we dealt with the FAT file system and 8.3Short Filenames. The command prompt could not work with more than 8 character filenames so we needed a way to access long windows filenames before quotation string support. 8 characters + 3 for the extension. And most systems still support 8.3 today. Here's an example.
C:\Program Files\Windows\System32\Calc.exe <- \Program Files\ is 13 characters
in order to CD into this path without quotes, you have to use the short path. like so.
CD C:\Progra~1\Windows\System32\Calc.exe <-- *Progra~1 is 8 characters, 1st occurrence.*
You just break the File or Folder name down to 6 characters, plus ~n (n=occurrence)
If we had a C:\Program Files (x86) path then, like we do today, it would be the 2nd path who's first 6 characters matched, and both exceeded 8 characters.
C:\Program Files becomes -> C:\Progra~1\
C:\Program Files (x86) becomes -> C:\Progra~2\
C:\MyLongFilename.txt becomes -> C:\MyLong~1\
Whenever I am having trouble accessing the full length file system through software that is unable to send escape sequences or quotations, some other kind of limitation, I have to resort to using the 8.3 short filename to access certain paths. On some Windows boxes, quotes won't even work and it will be some LONG process to enable them on the host machine. This makes for a good workaround when that happens.
Getting the short path (via sending to command prompt)
C:\ for %A in ("C:\Program Files (x86)\CMake\bin\cmake.exe") do #echo %~sA
will produce C:\Progra~1 for you to use
Or, get the short path by sending the path as an argument to a batch file.
::getShortPath.bat
#ECHO OFF
echo %~s1
USE:-> getShortPath.bat "C:\Program Files (x86)\CMake\bin\cmake.exe"
To wrap this up, here are three examples of what could be happening in the background behind CMake when a windows path is not resolving.
Not using quotations around the path
Using quotes works. But sometimes you can lose your quotes if the stdio >> runs through more than one process. In which case you'll need to send them in as escape sequences "\"C:/Program Files (x86)/CMake/bin/cmake.exe\""
4. Paths and Command Line Arguments need to be separate variable or instances from each other.
When sending arguments from CMake, you DO want them to be separate variables from the path variable. Set(CMAKE_EXE "C:\Program Files (x86)\CMake\bin\cmake.exe --version") will not work. Only paths and arguments with spaces in them need to be wrapped in quotes.
set(CMAKE_EXE "C:\Program Files (x86)\CMake\bin\cmake.exe" --version --trace "C:\My Soure Dir")
Putting it all together
If anyone is having problems with Windows/CMake paths like I was in the past, Study this code thoroughly until you completely understand it. All of the quotation placements. When you understanding what's quoted and what's not, and why, it should help a lot in the long run.
set(CMAKE_EXE "C:\Program Files (x86)\CMake\cmake.exe" CACHE INTERNAL "") <- make it a global variable.
set(ARGUMENTS --version --trace)
set(MyStringWithQuotesIncluded "\"This String wants it's quotes included\"")
set(MyCMakeLists "C:\MyApp\ProjectDirectory")
set(BuildHere "C:\MyBuilds\MyOSProject\bin")
set(FULL_COMMAND "${CMAKE_EXE}" ${ARGUMENTS} -DSTRING_VARIABLE="${MyStringWithQuotesIncluded}" -S "${MyCMakeLists}" -B "${BuildHere}")
execute_command(COMMAND cmd /c ${FULL_COMMAND} WORKING_DIRECTORY "${BuildHere}")
I had loads of issues working with windows paths through layers of CMake when I first started out. I hope this can help someone avoid all of that in the future.
Step 0: Install CMAKE
Make sure you have CMAKE installed on Windows:
https://cmake.org/download/
The installer will ask you if you want it to automatically set the PATH variable for you.
set the path to C:\Program Files\CMake\bin

1>Project : error PRJ0003 : Error spawning 'rc.exe'

1>Project : error PRJ0003 : Error spawning 'rc.exe'.. this is the error i get when i try to run this small practice program of reading and writing files which i cant do because of the reason of me not being able to get the files to open correctly. i use microsoft visual c++ 2008 and i have used the file path to try to open the file as well and i cant can someone help?
#include <iostream>
#include <fstream>
using namespace std;
int main ()
{
ifstream infile;
ofstream myfile;
int num;
infile.open("example.txt");
if(infile.fail())
{
cout << "error" << endl;
}
myfile.open ("example.txt");
if(infile.fail())
{
cout << "error" << endl;
}
while(!infile.eof())
{
example >> num;
}
while(!myfile.eof())
{
example << num;
}
infile.close();
myfile.close();
return 0;
}
The cause of the infamous: Error spawning 'rc.exe'
You freshly installed Visual Studio 2008 (VS2008)
Then dutifully patch with Service Pack 1 (SP1)
And find that VS environment variables are screwed up, like $(WindowsSdkDirs).
This happens when the service pack doesn't correctly tell the registry where to find the install directory. To fix this:
Close Visual Studio 2008
Start > Run > Regedit
Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows
Add new string value called CurrentInstallFolder (if it's not there already)
Give this key the value C:\Program Files\Microsoft SDKs\Windows\v6.0A\ (or wherever you installed it to)
When you restart VS2008, you ought to be able compile your program properly.
There's something wrong with your setup of Visual Studio, it should never have any trouble finding and running rc.exe. First thing to check if the file is there. It should be located in c:\program files\microsoft sdks\windows\v6.0a\bin\rc.exe.
Next thing to check is that the paths are set properly. Tools + Options, Projects and Solutions, C++ Directories. Upper right: Show directories for = Executable files. Verify that $(WindowsSdkDirs)\bin is listed there. Try adding the folder name explicitly. If the latter step works then your registry is messed up. Despair a bit, rerun Setup.exe and choose Repair.
Make sure one of the "Executable files" directories (editable via Tools->Options->VC++ Directories) contain both the RC.exe and RcDll.Dll.
The required RC.exe will most likely placed in "C:\Program Files\Microsoft SDKs\Windows\XXX\Bin" where XXX is the different version number.
If a particular version of Microsoft SDK didn't contain RC.exe, you might download the latest one from Microsoft and point the "Executable files" directly to the new directory, try to not use $(WindowsSdkDir) macro since it might still point to the old sdk directory.
Maybe your rc.exe is missing in this path:
c:\program files\microsoft sdks\windows\v6.0a\bin\rc.exe
If this is your problem you can copy this application from your friend's computer. hehe,..
I realize this is old, but I fixed the same error by checking the "tools" option when installing the Windows SDK. This is selected by default, I had removed it assuming Visual Studio's tools will be used.
(Using Windows SDK 7.1)
There is nothing to do in the Registry, nor in the Visual Studio settings!
You find a LOT of misleading and wrong answers to this question!
A detailed explanation of the problem can be found on the link below.
The missing files can be downloaded there, too.
http://netcult.ch/elmue/Error_spawning_rc.exe.htm
I had this case too.
From reading the answer by Elmue (elsewhere on this page) I found out it was caused by me having installed VS2008 + VS2010 + SDK then uninstalling all and deleting some folders manually. After reinstalling VS2008 and SDK in a nonstandard folder the RC.EXE file simply wasn't there, something got mixed up in the installation where some of the registry entries pointed to the SDK default folder (instead of the nonstandard one I used). Correcting the registry entries didn't work. Upon running Repair installation of SDK it just "corrected" the entries to point in the wrong direction again, but RC.EXE still didn't install.
In the end I had to bite the bitter apple: uninstalled everything and reinstalled SDK + VS2008 in their standard folders. Then it worked!