Visual Studio rebuilds the whole project every time I press Build > Build Solution (F7). Even when the code isn't modified.
It happens on all projects and I can reproduce the "bug" with a blank project. Apparently, it has something to do with tracking log files. Here is what you can find in the Diagnostic build log output:
pch.cpp will be compiled because it was not found in the tracking log. (TaskId:22)
Let me show you a complete example of my problem.
First, I create an empty project.
My Build and Run settings are the following.
The first time I build, I get the following:
1>------ Build started: Project: SimpleTrackingLogTest, Configuration: Debug Win32 ------
1>pch.cpp
1>SimpleTrackingLogTest.cpp
1>SimpleTrackingLogTest.vcxproj -> C:\kmasson\lab\SimpleTrackingLogTest\Debug\SimpleTrackingLogTest.exe
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
And the second time I build, without modifying the code, I get the exact same output.
In the full log located at Debug\SolutionName.log, you can find why all files were recompiled by searching for "will be compiled" using Ctrl+F. There is one line for each source file.
Read Tracking Logs: (TaskId:22)
Debug\SimpleTr.7CB9D8E0.tlog\CL.read.1.tlog (TaskId:22)
Outputs for ...\SIMPLETRACKINGLOGTEST\SIMPLETRACKINGLOGTEST\PCH.CPP: (TaskId:22)
...\SIMPLETRACKINGLOGTEST\SIMPLETRACKINGLOGTEST\DEBUG\PCH.OBJ (TaskId:22)
...\SIMPLETRACKINGLOGTEST\SIMPLETRACKINGLOGTEST\DEBUG\SIMPLETRACKINGLOGTEST.PCH (TaskId:22)
pch.cpp will be compiled because it was not found in the tracking log. (TaskId:22)
And CL.read.1.tlog contains many lines pointing to Program Files (x86) and Windows but also the 2 following lines (^ is really in the file):
^C:\...\SIMPLETRACKINGLOGTEST\SIMPLETRACKINGLOGTEST\PCH.CPP
... Some .DLL
^C:\...\SIMPLETRACKINGLOGTEST\SIMPLETRACKINGLOGTEST\SIMPLETRACKINGLOGTEST.CPP
... Many .DLL,.NDS, .H..
I don't understand why tracking log files aren't working. It happens on a big project I'm working on and it's just unusable, every time I want to build it rebuilds the whole project. Also, it seems that tracking log files are way to small for the big project I'm working on. Like it's not generating what it should.
I searched online about tracking log files but there is only little informations about them. I tried to reinstall completely Visual studio, disabling Windows Defender and deleting my local user Temp directory.
If you need any informations about my setup, please ask.
I found a way to get it working. It has something to do with the project's location. It works on C:\Users\kmasson but not in C:\kmasson. Though I have read/writting rights and I even tried to run VS as Administrator. I don't understand why it wasn't working but now the issue is fixed.
Related
I'm struggling with this for a long time now.
The setup:
c# project
c++ project
c# project has a reference for the c++ project with the following lines:
<ProjectReference Include="projectB.vcxproj">
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
<OutputItemType>Content</OutputItemType>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</ProjectReference>
This works from withing visual-studio.
This works when using devenv from command line.
When using msbuild from command line - the output file of the c++ project is not copied over into the output directory of the c# project.
I wasn't able to fix that using msbuild. Read a lot about it, nothing worked. Tried to debug in using diag verbosity - but logs of msbuild and visual-studio are very different...
I can't turn to using devenv as the build machine doesn't have valid visual-studio.
In msbuild log with diagnostic verbosity I see:
Target "GetCopyToOutputDirectoryItems" skipped. Previously built successfully.
This is where in the visual-studio log - it looks different - and actually works on copying the referenced native files to the c# output directory.
Perhaps something related with build order?..
In msbuild log - I also see:
Target "_CopyOutOfDateSourceItemsToOutputDirectoryAlways" skipped, due to false condition; ( '#(_SourceItemsToCopyToOutputDirectoryAlways)' != '' ) was evaluated as ( '' != '' ).
While in the visual-studio build log I see this target executed (it comes right after GetCopyToOutputDirectoryItems target)
Update 3:
It seems that previous solutions cause unwanted side-effects such as breaking the build when running multi-threaded builds.
Current solution, that does seem to work is to add:
<Targets>Build;BuiltProjectOutputGroup</Targets>
to the ProjectReference section.
Update 2:
Changing:
Targets="%(_MSBuildProjectReferenceExistent.Targets)"
to
Targets="%(_MSBuildProjectReferenceExistent.Targets);GetTargetPath"
in C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets, in the MSBuild task preceded by the comment Build referenced projects when building from the command line. - did the trick.
However, I have no confidence in this solution, as I don't understand the entire build process. This is just a guess.
Update 1:
using /p:DesignTimeBuild=true affects dependency build order. Can't work. Continue investigation...
Possible solution 1:
After putting a lot of messaged into C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets
I finally got to the following:
QUIRKING FOR DEV10
I'm still not exactly sure what that is all about, and I saw that the developers plan to remove this quirk (see https://github.com/Microsoft/msbuild/issues/1890).
Suddenly DesignTimeBuild caught my eye in the following line:
<Output TaskParameter="TargetOutputs" ItemName="_ResolvedProjectReferencePaths" Condition="'%(_MSBuildProjectReferenceExistent.ReferenceOutputAssembly)'=='true' or '$(DesignTimeBuild)' == 'true'"/>
I know that inside visual-studio this work. Googling got me to https://github.com/Microsoft/msbuild/wiki/MSBuild-Tips-&-Tricks.
From there the path was short to adding /p:DesignTimeBuild=true to the msbuild command line.
That made it work. The referenced assembly was copied over.
I don't think this should be the solution, but it works, and don't seem to break anything else (yet).
Any other suggestions would be welcome.
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]
I followed the instruction from this video to run the code line by line:
http://www.youtube.com/watch?v=6CGH9Z19dS8
However, after I pressed F8, it just ran without going to the breakpoint(I couldn't see the yellow triangle). In addition, I also tried "attach to process", and it was the same.
Did I miss anything?(btw, there are multiple files in my project, but I guess that won't be the problem, right? cuz I could do this easily in VS studio. Perhaps, I am not that familiar with codeblocks)
Thanks for help!
If you are interested, this is the debugger log:
Building to ensure sources are up-to-date
Selecting target:
Release
Adding source dir: C:\Users\liuca_000\Documents\Lattice_Boltzmann_code\lattice_boltzmann\
Adding source dir: C:\Users\liuca_000\Documents\Lattice_Boltzmann_code\lattice_boltzmann\
Adding file: C:\Users\liuca_000\Documents\Lattice_Boltzmann_code\lattice_boltzmann\bin\Release\lattice_boltzmann.exe
Changing directory to: C:/Users/liuca_000/Documents/Lattice_Boltzmann_code/lattice_boltzmann/.
Set variable: PATH=.;C:\Program Files (x86)\CodeBlocks\MinGW\bin;C:\Program Files (x86)\CodeBlocks\MinGW;C:\Python27\Lib\site-packages\PyQt4;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Python27;C:\Python27\DLLs;C:\Python27\Scripts;C:\Python27\Lib\site-packages\vtk;C:\Python27\gnuplot\binary;C:\Python27\Lib\site-packages\osgeo;C:\Program Files (x86)\pythonxy\SciTE-3.3.2-3;C:\Program Files (x86)\pythonxy\console;C:\MinGW32-xy\bin;C:\Program Files (x86)\pythonxy\swig;C:\Program Files (x86)\pythonxy\gettext\bin;C:\Program Files\MATLAB\R2012b\runtime\win64;C:\Program Files\MATLAB\R2012b\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files\MiKTeX 2.9\miktex\bin\x64;C:\Program Files (x86)\Windows Live\Shared;C:\Users\liuca_000\AppData\Roaming\MiKTeX\2.9\miktex\bin\x64;.;\
Starting debugger: C:\Program Files (x86)\CodeBlocks\MINGW\bin\gdb.exe -nx -fullname -quiet -args C:/Users/liuca_000/Documents/Lattice_Boltzmann_code/lattice_boltzmann/bin/Release/lattice_boltzmann.exe
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Reading symbols from C:\Users\liuca_000\Documents\Lattice_Boltzmann_code\lattice_boltzmann\bin\Release\lattice_boltzmann.exe...(no debugging symbols found)...done.
Debugger name and version: GNU gdb (GDB) 7.5
Child process PID: 16672
[Inferior 1 (process 16672) exited normally]
Debugger finished with status 0
Even if you have had marked -g compiler option the problem may be spaces in path to the project file. Moving to place with no spaces in path solved the problem in my case.
See that: http://wiki.codeblocks.org/index.php?title=Debugging_with_Code::Blocks#Path_with_spaces
I think this part of your log says why:
(no debugging symbols found)
build a debug version of your code - no optimisation, debug symbols included or built and try again.
Spent quite a while working through this today trying:
"Make sure using "debug" instead of "release"
"No spaces in directory names"
"-g ticked, -s unticked"
"download a nightly"
None worked until, I figured I had been making a very novice mistake unfamiliar with the IDE and to debug so it stops at the break points you have to run with the red arrow not the green one. So anyone as silly as me hopefully this helps! xD
You seem to have found a solution that is the wrong solution and likely
to have adverse consequences. (Apologies if I am mistaken)
Your were unable to set breakpoints because your build contained no debugging
information (as you now know); and the build contained no debugging information
because you were trying to debug a Release build and not a Debug build.
You can see this in the build log:
Adding file: C:\Users\liuca_000\Documents\Lattice_Boltzmann_code\lattice_boltzmann\bin\Release\lattice_boltzmann.exe
and also:
Reading symbols from C:\Users\liuca_000\Documents\Lattice_Boltzmann_code\lattice_boltzmann\bin\Release\lattice_boltzmann.exe...(no debugging symbols found)...done.
The executable generated by a Release build will be <project_dir>\bin\Release (as it is), and the executable
from a Debug build will be in <project_dir>\bin\Debug
It appears that you have "solved" the problem by going to Build Options -> Compiler flags and ticking
the checkbox Produce debugging symbols.
But if you go back there and look at the tree control at the left of the window I expect you
will see:
lattice_boltzmann
Debug
Release
with Release selected. That means you have now configured your Release build
to contain debugging information. You don't want that because:-
Although you will now get debugging symbols in the executable and the debugger will be able to use them, the Release build is still configured with high optimisation by default (as it should be) and you are very likely to find that the behaviour of the debugger is at times strangely puzzling, because the optimized object code doesn't always properly match up with the source code.
Your Release executable will be vastly inflated in size by the debugging information.
What you should have done is simply to ensure that the build you tried to debug was
a Debug build. To do that:
Navigate from the top menu bar Build -> Select Target
Uncheck Release. Check Debug
Then Rebuild the project (i.e. clean and build) and you will be able to debug it
properly. Code::Blocks default options for a Debug build are perfectly fine.
Don't forget to go back and remove the -g option from the Release configuration.
I've migrated a solution from VS2008 to VS2010 (SP1).
Now one of my project never finds peace in being up-to-date. Every build have the following output:
1>------ Build started: Project: PROJ_NAME, Configuration: Release Win32 ------
1>Build started 19/05/2011 7:59:27 AM.
1>InitializeBuildStatus:
1> Creating "Release\PROJ_NAME.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>ClCompile:
1> All outputs are up-to-date.
1> All outputs are up-to-date.
1>Lib:
1> All outputs are up-to-date.
1> PROJ_NAME.vcxproj -> C:\projFolder.PROJ_NAME.lib
1>FinalizeBuildStatus:
1> Deleting file "Release\PROJ_NAME.unsuccessfulbuild".
1> Touching "Release\PROJ_NAME.lastbuildstate".
1>
1>Build succeeded.
1>
1>Time Elapsed 00:00:00.09
========== Build: 1 succeeded, 0 failed, 5 up-to-date, 0 skipped ==========
Any ideas?
I had a similar problem when one of the include files listed in the project didn't actually exist. I had deleted the file, but forgot to remove it from the project.
The dependency checker then believes the project is not up to date, but the builder finds nothing to build.
I had two projects that contained the same file. When the second project built, it compiled the file again, changing the 'touch' datetime. That in turn set the 'AlwaysCreate' flag for the first project.
I found this out by turning on 'CPS' in my "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config" file, as in the xml snippet below. With that activated you can use the DebugView tool to get messages from VS2010 that state WHY it is rebuilding your project. Why those messages don't go into the build log is beyond me, but anyway there it is.
Add this:
<system.diagnostics>
<switches>
<add name="CPS" value="4" />
</switches>
</system.diagnostics>
To here:
<?xml version ="1.0"?>
<configuration>
<configSections>
<section name="msbuildToolsets" type="Microsoft.Build.BuildEngine.ToolsetConfigurationSection, Microsoft.Build.Engine, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</configSections>
<system.diagnostics>
<switches>
<add name="CPS" value="4" />
</switches>
</system.diagnostics>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0.30319" />
According to this thread on MSDN:
In my case in VS10 it was due to having missing (but non-complied .h files, thus no additional error to identify) in project folders.
A quick check that all project files can open in editor fixed this problem.
You must check also other files than .h. In my project Readme.txt was missed.
I moved a solution to a new folder, and every time I built a new version or tried to debug, it would want to claim that all the projects that made up the solution were out of date, even though it had just built them.
I searched all the .vcxproj files, used DebugView with CPS=4 (see #Bzzt's answer above) and discovered it was looking for the header files in their OLD location. Since the solution was moved, not copied, those files did not exist.
What finally solved it for me was cleaning the solution and doing one rebuild. After that the "AlwaysCreate" was no longer causing it the "build" all the sub projects. You have to clean each configuration (debug and release) separately, but once it has been rebuilt from the clean state, all is well.
In my case it didn't actually do any building, but MSBuild or whatever decided things were out of date, was using some cached filepath that no longer existed. The Clean and Rebuild replaced that cache and then it built like expected
I got the same issue.
Root-cause: incorrect build version of VS (32bit and 64bit)
Solution: Switch mode Debug/Release from 32 bit to 64 bit or reverse
http://postimg.org/image/3jurey1qr/
In Visual Studio 2010, I eliminated spurious rebuilds of a many-project solution by leaving Multiprocessor Compilation (/MP) unset (pity!). Previously, I had it enabled. Find the flag here: Common Properties > C/C++ > General > Multi-processor Compilation. Also, I noticed that I was able to eliminate individual projects' spurious rebuilds by rebuilding each project individually; then a build of each showed that each was up-to-date.
To get this to work, I simply renamed my existing output directory, in order to recreate all intermediate files (after trying all of the above accepted answers).
I've had success in the past using DebugView in VS2010 to find files to delete, but today that approach did not work. I could not find ANY reference to the missing header files, found using DebugView, within any of my code or project files XML. I also retrieved the outdated files from TFS to try with them both present and absent on my machine.
I then used GREP to search my entire solution directory, and the only results were in binary files: the old code files' *.obj, the project file's *.pdb, and vc100.idb. I don't know how these files get modified/replaced during build and rebuild, so I'm not sure if a previous reference in one of those files was responsible for claiming the old header files were missing.
Hope this helps someone down the road, and thanks for the above info that got me started!
For command line msbuild.exe builds you can use /verbosity:detailed and search the output for
"will be compiled as" to find compilations
"Source compilation required" to find links
Note: Output can be piped to file by using msbuild.exe /verbosity:detailed > output.txt
e.g.
code.cpp will be compiled as C:\path\to\header.h was modified at 18/02/2016 15:58:31.
Outputs for C:\path\to\code.cpp:
You may also find this happens after a windows update see this: Up to date projects compiled again because of TZRE.DLL date stamp is in the future after a windows update
The solution is to wait till that time, and the problem will magically vanish.
I just had the same problem, My TZRES.DLL file is 17/07/2018 19:54, the time now is 17/07/2018 15:15
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.