EDIT: See my answer below for the hotfix.
ORIGINAL QUESTION:
In setting up for our boat-programming adventure I have to set up source control and fix project files for a team to use them. (the project was previously only being worked on by one person who took shortcuts with setting up the project includes, etc)
I am fixing those SLN and Proj files. When trying to do a build on an external USB drive (I have not tried it on the primary hard drive) I am getting odd errors (lots of them for various files):
fatal error C1083: Cannot open
compiler generated file:
'.\Debug\.sbr': Permission
denied
These files are referenced in the vcproj file with relative paths in double quotes:
RelativePath="..\..\Source\.cpp"
I get the same errors form within a sln file in the IDE or if I call msbuild with the sln file.
The files are kind of "shared" for a few sln files (projects).
The person who originally created the SLN files is not known for being a wizard at configuring MSDev or making things work for teams.
Is this an issue with the way the source files are referenced? Any suggestions on how to fix these?
This URL does not seem to have helpful information:
Fatal Error C1083 on MSDN
Note - there were/are still hardcoded paths in the proj file, but i don;t see them for these files. They were mostly for the include and lib dirs. I think I removed them all.
I also get these errors:
..\..\Source\.cpp : error C2471:
cannot update program database '\debug\vc90.pdb'
..\..\Source\.cpp(336) : fatal
error C1903: unable to recover from
previous error(s); stopping
compilation
..\..\Source\.cpp(336) : error
C2418: cannot delete browser file:
.\Debug\.sbr
Title: You may receive a "PRJ0008" or "C2471" or "C1083" or "D8022" or "LNK1103" or similar error message when you try to build a solution in Visual C++
Symptoms:
D8022 : Cannot open 'RSP00000215921192.rsp'
PRJ0008 : Could not delete file 'vc90.idb'.
C1083 : Cannot open program database file 'vc90.pdb'
C2471 : Cannot update program database 'vc90.pdb'
LNK1103 : debugging information corrupt.
Cause:
This problem occurs when all of the following conditions are true:
You have a solution with more than one project in it.
Two or more of the projects are not dependent on each other.
You have parallel builds enabled. (Tools -> Options: Projects and Solutions, Build and Run: "maximum number of parallel project builds" is set to a value greater than 1)
You are building on a system with multiple CPUs (cores).
Two or more of the non-dependent projects are configured to use the same Intermediate and/or Output directory.
A specific race condition in mspdbsrv.exe remains uncorrected.
Resolution:
To resolve the problem do one or more of the following:
Reconfigure the non-dependent projects to specify an Intermediate and Output directory that is different from one another, e.g. Output Directory = "$(SolutionDir)$(ProjectName)\$(ConfigurationName)", Intermediate Directory = "$(OutDir)".
Adjust your solution's project dependencies (Project -> Project Dependencies...) so that each is dependent on another.
Disable parallel builds.
Add the "/onecpu" boot option to your boot.ini file.
Change you BIOS settings to enable/use only one CPU.
File a problem report with Microsoft Technical Support and keep bugging the crap out of them until they eventually fix mspdbsrv.
Status:
The problem is a combination of both a user project configuration error as well as a race condition in Microsoft's "mspdbsrv.exe" utility that does not properly handle more than one thread calling it at the same time for the same file resulting in the file's HANDLE being left open.
Additionally Visual Studio itself and/or its build system (VCBUILD and/or MSBUILD) (or all three!) should be made smart enough to detect and alert the user of such user errors so that corrective action can be taken.
This problem has been around for a LOOOOOONG time.
Applies to:
Microsoft Visual C++ 2005
Microsoft Visual C++ 2008
Others?
Respectfully submitted:
"Fish" (David B. Trout)
fish#infidels.org
p.s:
You're welcome. :)
Hmmm.
Perhaps:
http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/0ceac3c6-62f6-4fdf-82e1-d41e1b4fcd20/
there is a hotfix from MS
http://code.msdn.microsoft.com/KB946040
http://support.microsoft.com/kb/946040
That might be my problem. I think it might only be on one machine I have.
EDIT:
I downloaded and ran the hotfix installer. It seems to have fixed it.
I get this same error when I physically remove a file from disk, but leave it in VS. In VS2005 it would give a much better : fatal error file not found. I think this is a bug in VS2008. The hotfix mentioned above didn't help me.
In my case it was my virus package (Trend Micro) causing all the problems. I added my Dev folders to the Ignore/White lists to solve the problem
delete your debug folder and build your project agian.
Occastionally my Visual Studio will suddenly decide something like this. I have found it maybe help to toggle to release, do a full rebuild, then toggle back to debug.
Related
VS2017, SDK/WDK, C++ project
we have a c++ solution (driver) that is shared across developers via Team Foundation Services - visualstudio.com (now called azure devops?).
When I perform a get latest source code, and want to rebuild the solution I get two MSB3030 errors:
"Could not copy the file "C:\path of my colleague his file" because it was not found."
I found it strange that I saw on one of the two errors a path of my colleague his pc. He works on C:\ I'm working on E:\
Unloading the project, I saw he path being set here:
<ItemGroup>
<FilesToPackage Include="C:\path of my colleague\foo.xml" Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
<PackageRelativeDirectory>
</PackageRelativeDirectory>
</FilesToPackage>
We cannot get this solution to build because of the MSB3030. First we have to clean the specific projects individually, rebuild it, then build another project etc.. a few steps to perform manually in the correct order , trial and error, drinking coffee, throwing bananas to the pc and praying that a monkey outputs the code correctly.
Has anyone seen somehting similar regarding MSB3030 errors?
On my pc I see the path of my colleague, but he doesn't see my path (strange!).
C:\Program Files (x86)\Windows
Kits\10\build\WindowsDriver.common.targets(1699,5): error MSB3030:
Could not copy the file 'C:...' because it was not found.
I've set the Any CPU to x64 because it doesn't make any sense for c++.
C++ Windows Driver MSB3030 could not copy the file '' because it was not found
The reason for this issue is that the path of the ItemGroup is an absolute path in the project file:
<ItemGroup>
<FilesToPackage Include="C:\path of my colleague\foo.xml" ...>
...
</FilesToPackage>
</ItemGroup>
Regardless of whether your colleague has added this file to source control, when you pull the code from the TFS server to your local and put the code in a different local folder, the absolute path will bring you a lot of trouble, you need to manually check the code on the TFS server for this file and you need to modify the absolute path of this file in your project. But this problem will reappear after your colleague updates after you submit your code. Because an absolute path cannot be assigned to two different paths C:\ and E:\.
To resolve this issue, you need to change the absolute path to a relative path in the source code. Generally, we prefer to add this file to the Solution/Project folder, then use the MSBuild Macros $(SolutionDir)/$(ProjectDir) to specify it.
Check Common macros for build commands and properties for some more details.
Hope this helps.
When trying to load an existing project on Visual Studio 2008 Service Pack 1 I get the following error
The following error has occurred during XML parsing:
File: C:\pathTo.vcproj
Line: 49501
Column: 6
Error Message:
System error: -2147154682
The line where it fails is on a moc file that doesn't exists because as a moc file it will get generated during the build. The weird thing is that there are several moc files in other projects but not all of them fail to load only certain ones.
Thanks to Anon Mail's comment, I figured out what was needed.
I am not providing a full explanation of the answer because I don't fully understand the black magic behind it but here's what I did to fix my problem:
Make a copy of the incriminated .vcproj file :)
Manually change the .vcproj file and remove all the files (in my case all the mocs) that fails to load as Anon Mail suggested.
The project should then be loaded correctly
Once loaded close Visual Studio and restore the previous .vcproj file
Open up your solution and it should be fine.
Again, I don't really understand why it works this way but I hope this may help someone else in the future.
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'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