c1010070: Failed to load and parse the manifest - c++

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]

Related

msbuild doesn't copy output of referenced native project to c# project out dir

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.

Issu using startMATLAB in C++ with "MatlabEngine.hpp" in r2017b

In its new version 2017b, Matlab has released a new MATLAB Engine API for C++: https://fr.mathworks.com/help/matlab/calling-matlab-engine-from-cpp-programs.html
When I try to use this API, (only to start Matlab at the beginning !!), I have an issue using :
std::unique_ptr<MATLABEngine> matlabPtr = startMATLAB();
The compilation is ok, but at the execution :
Here is the call stack:
matlab::engine::initSession --> matlab::engine::startMATLAB -->
matlab::engine::startMATLABAsync --> engine_create_session
Now, I use a different way to do my job, but I don't want to let an issue without a solution. Can someone spot the problem with this API?
My configuration :
Matlab 2017b
Visual Studio 2017
Windows 10
Just a few days back, I had the same issue: here
So, I had raised a ticket in MATLAB for technical support. And they suggested to build the project in the following manner which works for me:
Create a project and add the source file.
Go to the project properties, and do the following changes(Make sure to change the architecture to X64):
Under C/C++ General, add the following directory to the field
ADDITIONAL INCLUDE DIRECTORIES: C:\Program Files\MATLAB\\extern\include
Under C/C++ Precompiled Headers, select "Not Using Precompiled
Headers".
Under Linker General, add the directory to the field ADDITIONAL
LIBRARY DIRECTORIES: C:\Program
Files\MATLAB\\extern\lib\win64\microsoft
e. Under Configuration Properties ->Debugging Add the following 2
Target paths in the Environment: PATH=C:\Program
Files\MATLAB\\bin\win64; PATH=C:\Program
Files\MATLAB\\extern\bin\win64;
Under Linker Input, add the following names to the field marked ADDITIONAL DEPENDENCIES:
libmat.lib
libMatlabEngine.lib
libMatlabDataArray.lib
Make sure that the following directory is in the Windows system
environment PATH: C:\Program Files\MATLAB\\bin\win64;
C:\Program Files\MATLAB\\extern\bin\win64
Now, build the project and run your application.
Like in the comment, I solved the issue by upgrading Matlab from R2017b to R2018b!
I noticed the same issue testing R2020b
while it worked fine with R2020a, a run-time error occurs with R2020b when running
std::unique_ptr matlabPtr = startMATLAB();

x64 build: error MSB8013: This project doesn't contain the Configuration and Platform combination of Debug|Win32

I'm trying to get a pure x64 build running for a complex build with many solutions (some for CI, some for devs) and hundreds of project and have run into "error MSB8013: This project doesn't contain the Configuration and Platform combination of Debug|Win32"
I've reduced it to a simple configuration:
Solution A contains Project X & Project Y. Project X has a project
reference to Project Y.
Solution B contains also contains Project X.
None of the projects or solutions contain a Win32 platform - it's been deleted.
When I build solution B (as x64), I receive
error MSB8013: This project doesn't contain the Configuration and
Platform combination of Debug|Win32
The error message sometimes contains additional information:
This error may also appear if some other project is trying to follow a
project-to-project reference to this project, this project has been
unloaded or is not included in the solution, and the referencing
project does not build using the same or an equivalent Configuration
or Platform.
The problem is the referencing project does "build using the same or an equivalent Configuration or Platform."
Looking at the msbuild diagnostic, project Y is being built because project X contains a project reference to it. But the configuration and platform properties are being deleted just before project Y is built:
1>Task "MSBuild" (TaskId:28)
1> Removing Properties: (TaskId:28)
1> Configuration (TaskId:28)
1> Platform (TaskId:28)
As a result Microsoft.Cpp.Default.props kicks in and sets these to Debug|Win32:
1>Task "Message" (TaskId:11)
1> Configuration=Debug (TaskId:11)
1>Done executing task "Message". (TaskId:11)
1>Task "Message" (TaskId:12)
1> Platform=Win32 (TaskId:12)
1>Done executing task "Message". (TaskId:12)
How can I prevent this and make msbuild pass the chosen configuration & platform?
(I understand the ultimate solution to use NuGet to manage package dependencies, but that isn't feasible in the short term)
I could resolve a similar issue by including all referenced projects into the solution - in this case including Project Y into solution B.
One fix is to hand edit the .vcxproj files to define the default platform:
Open the vcxproj file in a text editor
Add this line in the "Globals" PropertyGroup:
<Platform Condition="'$(Platform)' == ''">x64</Platform>
It seems it is a bug in Microsoft.CppBuild.targets file. On some machines I see two such files: one in C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppBuild.targets with ~120KB size, and C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets with 77KB size. Second one is buggy and gets wrong $(Configuration)|$(Platform) value which yields mentioned error. This problem is probably directly connected with this topic, as VCTargetsPath in my projects pointed into wrong (77KB) Microsoft.CppBuild.targets directory (I use VS2015 so it should use the one from V140 directory). I found two workarounds: 1) replace buggy file or 2) modify HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSBuild\ToolsVersions\14.0\14.0\VCTargetsPath10 registry to point right file.
I couldn't add a comment because of lack of rep, but in the same vein of user1825216's answer, I'm running MSBuild from a command line so I resolved this error by adding -p:Platform=x64 to the build command instead of modifying the .vcxproj.
I find it difficult to see what you're trying to achieve through this. Do you always want to build X AND Y? Even in the solution that has no reference to Y? Would be fairly illogical to me. Though, I can offer you some solutions to fixing / supressing this issue, based on what you want.
If you want to build X&Y with A and X with B
In Solution A, set the other project as a build dependency, instead of referencing project Y in project X. You can't set it as long as it refers to the other project (I always remove the reference in the .vcxproj, it's somewhere at the bottom of the project), but once you removed the inner project reference, you can have the solution reference to it and then it should work just fine.
When you build Solution A with MSBuild, it'll build X AND Y, while building solution B with MSBuild
Else
If you want to build X&Y with either solution
Sorry, but that's not really possible within MSBuild at the moment. I'd recommend adding project Y to the solution and referencing it, but then, why would you? You already have a project that has them both included, and if you want different outputs, you can easily make different configurations.

what microsoft visual studio 2010 build message mean? [duplicate]

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

VC2008 compiler errors opening sbr files (C2418 C1903 C2471)

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.