I am getting following error while building my vc++ project (Using visual studio 2010)
RC : fatal error RC1107: invalid usage; use RC /? for
I know there is some issue while building resources but how to get the exact problem area?
Thanks
Solution:
Add a slash to the last include path will do the trick.
If your last include path already contain a slash at the end, delete it will also work.
Note: Some other include paths can cause this too; it doesn't have to be the very last include path. In particular, check the last include path that you add (in addition to the built-in ones) in your project/properties file.
I had a similar problem. I solved it removing the trailing backslash from the last path in Include Directories (from Project Properties | Configuration Properties | VC++ Directories).
I got this when upgrading from VS2008 to VS2010. None of the suggested solutions worked for me.
What worked for me was deleting all the files in the configuration build folder (e.g. Release) and rebuilding the solution.
I also solved this problem by removing VS include path "\" from last entry.
My solution for VS2010:
click menu "Project","Properties" to open Property pages.
click "Configuration properties", "general" to change Output Directory from "$(Configuration)\ \" to "$(Configuration)\" ,change interminably directory from "$(SolutionDir)$(Configuration)\ \" to "$(SolutionDir)$(Configuration)\".recompile and it's OK.
I experienced that both with VS2015 and VS2017 .
Pls look in 1, at the answer of AH214.
In some cases the Resource Compiler fails to understand the options of the RC command line created by Visual Studio .
To find the problematic option do:
In VS2015, as described by AH214, copy the command line options listed in Project -> properties -> Configuration Properties -> Resources -> Command Line .
Find some *.rc file on your machine.
Open Visual Studio command prompt.
Issue the command
RC [the options copied in (1)] [the path to the rc file in (2)] .
You should get the same RC1107 error.
Check in this property page the contents of ...Resources -> All
Options . Look for a suspicious option and fix or remove it.
Repeat (4) and (5) till you do not get the RC1107 error in (4).
Once you found the culprit, check if you can change it or even remove
it.
I had this issue with VS 2017. The problem was that I did not notice that I had the build configuration set to Release and there was a string in one of the controls that was too long and needed to be truncated by the resource editor when the resources were loaded. Putting the build configuration back to Debug and attempting to open the Resource file fixed it. I got a different message this time: string too long - truncated, and the resources could be viewed now.
the backslash trick didnt work for me. but i just added a new icon to the RC file and then it worked all fine for me.
Related
I was trying to #include a cpp file with some functions so I can use that cpp file later with other projects. It gave me an 'already defined in .obj' error and since then that .cpp file was like binded with my project. (I understood that's not the way, the answer here helped me with the already defined)
If I exclude the .cpp file from the project, remove it from the directory and remove the #include line it still looks for it:
c1xx : fatal error C1083: Cannot open source file: 'std.cpp': No such file or directory
Diagnostic:
Outputs for D:\MY DOCUMENTS\C#\PROJECT\D3DTESTC++\COWS AND BULLS\CBMAIN.CPP|D:\MY DOCUMENTS\C#\PROJECT\D3DTESTC++\COWS AND BULLS\STD.CPP: (TaskId:15)
It shouldn't be looking for the std.cpp at all, I removed it! So is there a way I can reset the project and recompile so that the program doesn't look for it? I already tried Rebuild and Clear -> Build Project
When I ran across a similar problem with VS Express, I wound up having to open up the the .vcxproj file (which is just XML), and remove the offending
< ClInclude Include="FILEPATHANDNAME" > tags.
Many of the solutions here will not work
Fullproof method:
Open the vxproj file that is giving you trouble in a text editor.
remove all references to the file it cannot find.
OK, I have no idea how I did it but I'm still going to try to write what I did.
Save all and Close solution
Open the .vcxproj file (not .sln)
Build -> Clean [Project Name]
Save all and Close
Open the .sln file again.
Build -> Project Only -> Clean Only [Project Name]
Build -> Project Only -> Build Only [Project Name]
That's exactly what I did and worked for me. I think the main thing to do is clean, save, close, open, build, but I'm not sure.
In Solution Explorer you can select/deselect option "Show All Files".
Try both options and make sure excluded file is not included in project for both of them.
That's what I had:
I used "Show All Files" option (so you can see all the files in project directories). I excluded one of my .cpp files from project. However, it behaved as this file is in project.
That's how I managed to fix it:
I switched "Show All Files" off and saw this file still belongs to project! So I excluded this file once again.
As I see, that's a known issue.
This worked for me, hope it will be useful for someone else.
Try to verbose builder output to see exact steps of what's going on. I suppose, you use Visual Studio, right?
Go to menu "Tools -> Options"
In options dialog, select "Projects and Solutions -> Build and Run"
Change current mode of "MSBuild project build output verbosity" from "Minimal" to something like "Diagnostics" or "Detailed".
Rebuild your project and investigate Output windows
Builder dump should shed more light on your current settings (I suspect you have more references to that file than you expect)
This happened to me because I renamed folder from inside the IDE. None of the above solutions worked. The only way to fix this is by opening vcproj in notepad and you should see the offending files in the <ItemGroup>. Just delete those lines.
Or sometimes, like in my case, the issue is simply in the naming of the folders in the location. I had a very long path with folders that I like to name with special characters so they show up at the top and it's easy to access them.
As soon as I put my solution in a folder just in D: drive, the issue was gone.
When I renamed a file, I found I had to go to SolutionExplorer, Source File, select the file, first exclude from Project, then re-add it to project, and rebuild the solution it lives in. It was still showing up as the old file name under Source Files for me.
I had the same problem, but I had another .sln worked fine. After tooling around with the Project->Properties-> to make them look identical, nothing worked. I opened both .vcxproj files and copied the contents of the working version into my non-working version. (I noticed that the two files had different lengths. The non-working version was longer by about 20 lines.) I just changed the RootNameSpace to the non-working version's name. I saved the non-working file and presto! It worked.
I removed those sources from Project and re-added them. Somehow, references were messed up after a hurry project refactoring.
For people having problem related to "error C1083: Cannot open source file":
Error is caused by settings in *.vcxproj file. Probably you deleted/moved source file by file explorer, not by Visual Studio's "Solution Explorer". Thus, your *.vcxproj file is corrupted. Fix is to manually correct settings in *.vcxproj file.
How Visual Studio settings files work
Visual Studio saves solution's info into file. This file is usually in project's solution directory, has extension .sln and base name is same as name of solution, f.ex.:
NameOfSolution.sln
Similarly, project's info is saved into one file (each project has its own file). Base name of this file is name of project, extension is .vcxproj, and usually is located in subdirectory named as your project, f.ex.:
NameOf1stProject/NameOf1stProject.vcxproj
NameOf2ndProject/NameOf2ndProject.vcxproj
Both *.sln and *.vcxproj files are textual files. You can open them by using Notepad.
How to fix problem
Find *.vcxproj file responsible for your project.
If you don't know where it is, open in Notepad the *.sln file of your solution. Search for name of your solution. You will find line like:
Project("{9AA9CEB8-8B4A-11D0-8D22-00B0C01AA943}") = "NameOf1stProject", "NameOf1stProject\NameOf1stProject.vcxproj", "{A8735D0A-25ED-4285-AB8F-AF578D8DB960}"
Value under "NameOf1stProject\NameOf1stProject.vcxproj" is location of *.vcxproj file of your project.
Open found *.vcxproj file by text editor (f.ex. Notepad).
Search for line on which is filename you are struggling with.
Example: if you are looking for "RemovedFile.cpp", then you should find line:
<ClCompile Include="RemovedFile.cpp" />
Delete that line.
If you have opened Visual Studio, it asks you if it should refresh solution - select yes. If it is not opened - just start using it.
In case of any problems, try to rebuild solution (top banner -> Build -> Rebuild Solution)
In my cases, it worked. 30 mins of trying to fix, <1 minute of fixing.
This helped in my case. To sum it up, my path to the project was too long, so I moved my project to something shorter i.e. D:\my_project and everything worked in a blink of an eye.
I had this same problem, but for me the issues was that I was using Bash on Windows (WSL) to clone the repository and then using VS to compile.
Once I deleted my clone and used Windows command line (cmd.exe) to clone the repo then the error 1083 went away.
This is caused by not removing/deleting the file properly. Go to Solution Explorer, select your solution, at the left corner, activate the icon: show all files.
(if you already removed the problem file, restore it from recycle bin)
Select the problem file, do remove and delete from within Solution Explorer and you should not have this problem. And remember to do it the proper way from now on.
This is on MS 2010
If you have that file in your project directory but you still got the error, on your IDE go to Solution explorer--> Remove that file-->then open the project directory on your file explorer-->Select that file and drop it on a specific location in IDE solution explorer. I fixed it this way. I use the Windows platform.
I got this error when I got a code from my peer and I tried directly running it on my system. Ideally to avoid such errors, I should have just copied the source and header files and should have created the VS solution of my own.
To resolve the errors I removed the files from the Solution Explorer and added them again. Following image shows the Solution Explorer window.
The remove option comes after right clicking on the file names.
I have received a project from another. When I built, this error occured. I tried to search Google to solve this problem and I followed this link but no effect.
Try doing Rebuild instead of Build. If this doesn't work, try deleting or renaming the Debug and Release directories, and build again.
Keep in mind that Visual Studio often has 2 sets of Release and Debug directories - one set at the top level directory for the solution, and one at the directory for the project.
This could be due to the length of the path for the intermediate files.
The max path length for visual studio is somewhere around 256 characters.
Whilst considering path lengths don't forget that the compiler may use paths such as C:\folder1\folder2\folder3\..\..\folder1a\file.obj, which is longer than you expect for the file C:\folder1\folder1a\file.obj.
Inspect your project settings or build output to see what paths are being used, and perhaps try shortening them.
My problem was case sensitive in Windows 10 for partition e:
I have fixed with:
fsutil.exe file setCaseSensitiveInfo "e:\" disable
I faced the same problem, and it's because I changed my folder name.
ex: I build the solution when its folder name is 'Folder1' and then I close the entire solution and change my folder name into 'Folder2'. When I re-open the solution, and tried to build it, it has error "Fatal error C1083: Cannot open compiler intermediate file: '*\Folder1*.pch': No such file or directory"
But as satuon said, I tried to rebuild instead of build the solution, it's then working.
I was working in visual studio, and I made a few changes to one of my projects (changed a few include directories). When I tried to build that project later on I got the following error message:
cl : Command line error D8036: '/Fo.\obj\ms100_r' not allowed with multiple source files
I don't see how that is relevant to what I changed at all. I even rolled my .vcxproj file back to the previous version and that error still persists. I am clueless as to what is causing it. Aren't command line parameters supposed to be managed by visual studio anyway?
had the same problem and realized i had removed the slash at the end of:
configuration properties->c/c++->output files->object file name->
once i added back the slash at the end of the file name, everything worked again
I had a similar error with /doc. For me the solution was to change Configuration Properties / C/C++ / Output Files | XML Documentation File Name from "$(TargetPath).xml" to empty string.
this error due invalid setting in project Browse information .
goto configuration > C/C++ > Browse information > Enable Browse Information to None
A twisted variation on the selected answer is if you use quotes around pathname. The backslash must be the last character.
So:
/Fa"\base\some dir\" will fail
/Fa"\base\some dir"\ will work
I'm trying to compile a C++ type .DLL for a SierraChart custom study.
(Which is a financial trading application.) Here is the warning I get that I need to fix so it all points to the linker output value:
warning MSB8012:
TargetPath(C:\SierraChart\VCProject\Release\SCStudies.dll) does not match the Linker's
OutputFile property value (c:\sierrachart\data\SCStudies.dll).
This may cause your project to build incorrectly. To correct this, please
make sure that $(OutDir), $(TargetName) and $(TargetExt)
property values match the value specified in %(Link.OutputFile).
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets
Any idea what's wrong?
I believe this warning appears specifically when upgrading a C++ project to VS2010. Visual Studio 2010 C++ Project Upgrade Guide describes some of the caveats encountered during an upgrade. If you're uncomfortable changing project settings, then retaining the older version of Visual Studio, may work for you.
To change the %(Link.OutputFile), open the project properties. Navigate to Configuration Properties -> Linker -> General. You can set the Output File to $(OutDir)\SCStudies.dll, which should take care of your issue. You may need to repeat the change for each Configuration/Flavor you will be building (Debug/x86, Release/x86, Debug/Itanium, etc...).
Based on this answer.
I changed the following property:
Linker -> General -> Output File to
"$(OutDir)$(TargetName)$(TargetExt)"
This prevented the warning to appear and the output was generated successfully.
The original configuration was set like:
Properties -> Linker -> General : $(OutDir)\"<'name fileA>".exe
The program tries to run "<'name_project>".exe and as result error Linked.
You need to set the configuration as:
Properties -> Linker -> General : $(OutDir)\"<'project name>".exe
A different fix which others haven't mentioned is that by default the TargetExt is .exe and for my debug builds I changed it to be _d.exe, where instead you should be doing that in the TargetName path.
The directory specified in General->Output Directory and the directory specified in the path at Linker->Output File have to match.
If you want to change the defaults do things in these order:
You first configure the OutDir in General->Output Directory. E.g.
$(SolutionDir)$(Platform)\$(Configuration)\MyProgram\
Make sure Output File is consistent. E.g. this would work
$(OutDir)\$(TargetName)$(TargetExt)
The comment from Gerardo Hernandez helped me.
The directory specified in General->Output Directory and the directory specified in the path at Linker->Output File have to match.
In my case I was importing a large project from Visual Studio 6 and
C:\Project\myproject\OneOfMyDlls\.\Debug\OneOfMyDlls.dll
was not equal to
C:\Project\myproject\Debug\OneOfMyDlls.dll
but
C:\Project\myproject\OneOfMyDlls\..\Debug\OneOfMyDlls.dll
would have been, after path reduction.
The problem was that the Visual Studio 2017 import had changed the output directory from
..\Debug to .\Debug assuming that the unconventional parent directory use was a mistake. In a large project with 13 DLLs of our own, (never mind second and third party DLLs too), it makes sense to collect all the DLLs in one place and ..\Debug was correct.
So while others might have had to change Linker->Output File, in my case it was General->Output Directory which needed to change as it had been corrupted by the import from Visual Studio 6.
Something like ..\Debug had become something like .\Debug after import. (The real project specific names have been removed .)
Looks like it's not significant for the program:
Odd Visual Studio error when following the custom study video
If, like me, you return to Visual Studio after 20 years, you may not know where the project properties are. In VS 2012: top of the screen "FILE EDIT VIEW PROJECT BUILD..." : choose PROJECT. Properties is the last item in the menu. Indeed for me there was a mismatch in the target name, too.
I had a VC2008 project very complicated.Inorder to understand it's inner workings I tried to simplify it and now I am getting 289 errors of the following type for most of the files:
Error 5 error C2471: cannot update program database 'c:\users\ryan\documents\visual studio 2008\projects\vc\myinfo\cli\debug\vc90.pdb' c:\users\ryan\documents\visual studio 2008\projects\vc\myinfo\cli\mediainfo\file__analyze_buffer_minimizesize.cpp 1 CLI
Error 6 fatal error C1083: Cannot open program database file: 'c:\users\ryan\documents\visual studio 2008\projects\vc\myinfo\cli\debug\vc90.pdb': No such file or directory c:\users\ryan\documents\visual studio 2008\projects\vc\myinfo\cli\mediainfo\file__analyze_buffer_minimizesize.cpp 1 CLI
My system : win7/VS2008
Solution 1: Locate *.vcxproj file in your solution, open in a text editor and search for 'DebugInformationFormat' and set it to 'OldStyle'. Reload your project and build. If you have multiple projects in your solution, this change needed for all the *.vcxproj files.
< DebugInformationFormat>OldStyle< /DebugInformationFormat>
Solution 2: From Visual Studio, on every project in your solution right click and open Properties. Expand 'Configuration Properties' > 'C/C++' > 'General'. Change the 'Debug Information Format' to 'C7 compatible (/Z7)'. Then build your solution.
This worked for me. (YMMV = Your mileage may vary:)
I've seen the same behaviour when converting a VS2003.Net solution to run on later IDEs. My guess is that your solution contains multiple projects which point to the same intermediate directory. In VS2005 and later, projects that don't depend on each other can be built in parallel so that if the same working dir is used, you can get file conflicts like this.
Check this as follows. In Solution Explorer, right click on one of the failing projects and select Properties. In Configuration Properties -> General section, make sure that every project has a different 'Intermediate Directory'. Try your build again using 'Rebuild Solution' to clean everything out.
Most of the times when I get "C2471: cannot update program database" it's because the PDB file is locked for some reason. Usually in my case that turns out to be because I have the program running in some other window, which loads the PDB file in to memory.
When that's not the reason, I find doing a rebuild-all magically fixes the problem.
I've encountered the same type of error myself with no end of frustration.
I finally fixed it by applying the Microsoft hot fix found in this knowledge base article: http://archive.msdn.microsoft.com/KB946040
This worked for me.
Kill mspdbsrv.exe and reload Visual C++
MSDN
You can delete the *.obj file and rebuild the solution again, This problem might solve. Below link might be helpful for you-
https://social.msdn.microsoft.com/Forums/vstudio/en-US/0ceac3c6-62f6-4fdf-82e1-d41e1b4fcd20/vs2008-c2471-cannot-update-program-database?forum=vclanguage