Our team is migrating whole baseline from VS2008 to VS2012. There're over 400 C++ projects. There're 6 C++ project show wired error, such as :
1>------ Rebuild All started: Project: SSLT, Configuration: Release Win32 ------
1> stdafx.cpp
1> ???
1>c1xx : fatal error C1083: Cannot open source file: '???': No such file or directory
1> ??????????????????????????????
1>c1xx : fatal error C1083: Cannot open source file: '??????????????????????????????': No such file or directory
All files which are the parameters of cl.exe seems in wrong encoding, and cl.exe can't find them.
Firstly, i think it must be encode issues of .vcxproj, so i save as other encoding style. But still happens.
Then i re-upgrade these projects with such issue, but always build error.
At last, I change the project platform toolset back to VS2008, then build pass. So i think it's not because project file encode format. I don't know what wrong with them when using 2012 compiler. These projects build no error using 2008 compiler. And as i know from VS2010, project format changed a lot, so i can't find any clue.
Btw, there's another reason cause such issue. After upgrade, there's one property in *.vcxproj file made an unproper line break, such as:
/Zm300
/bigobj %(AdditionalOptions)
if i change it back to:
/Zm300 /bigobj %(AdditionalOptions)
Then works well, build pass.
The projects which has such issue, 80% of them are because of such issue.
Create a new sample project to see which encoding the VS expects and then convert your files to it.
Alternatively, How to: Upgrade Visual C++ Projects to Visual Studio 2012 says that you must upgrade a VS2008 project upon opening it in VS2012.
I don't have a VS2012 installation to check this, but there may be a function to convert a project programmatically in one of its DLLs - try searching with a dumpbin-based script or by examining stack traces with procmon while converting a sample project.
Thanks for your reply, i automatically upgrade our projects using: devenv.exe /upgrade *.vcproj in script.
Today i find the root cause is precompile header file: stdafx.h.
It is because that wrong precompiling head file reference. It will cause mess file name issue.
Related
Recently I tried opening up Visual Studio 2019 because I wanted to try I new IDE when I was met with hundreds of errors upon running standard boilerplate c++ code. More specifically import errors. I have tried installing the newest version of Visual Studio, have tried adding the path manually to the "Additional Include Directories and modifying my installation but nothings worked.
Update: In the build errors I got the following error
fatal error C1083: Cannot open include file: 'crtdbg.h': No such file or directory
and when I checked the directory where I would expect the header file to be it wasn't there.
1.Check the C++ windows sdk version in VS Installer.
2.Make sure that the installed windows sdk is selected in your project properties.
I have several Visual C++ projects (.vcxproj) that we have in a Visual Studio 2013 Solution. From a clean code pull, everything builds successfully in either Visual Studio 2013 or a build script that calls MSBuild on each project in the proper order (a relic from the days of old, which we are working, slowly but surely, to replace).
We have a few issues with this. First, if we build from the build script first, and then try to debug, it says that most of the projects are out of date. This is annoying, but I think this is due to the batch file not touching something in the intermediate directory the same that Visual Studio does. I find similar problems documented at Stack Overflow and Microsoft Connect. Is there an alternative to modifying the Microsoft.CppBuild.targets file? I'd like to have a fix for this that doesn't involve manually modifying all of the developer's machines.
The primary problem is: If we build a project from within Visual Studio 2013, it will build and link successfully. However, if we then go and build the same project from the build script, we get:
OtherProject.lib(SomeObject.obj) : error LNK2011: precompiled object not linked in; image may not run [Full path to .vcxproj]
OutputFile.dll : fatal error LNK1120: 1 unresolved externals [full path to .vcxproj]
Does anyone have tips on how to figure out which precompiled object this is as well as why the Visual Studio based build could manage to figure things out? Do I need to review every library dependency, and each of their dependencies? Is there an easier/automated way to do this? One thing to note is that Visual Studio 2013 does not always get it right and fails with the same warning.
Our batch file build command is:
msbuild /nologo /maxcpucount /clp:NoSummary /p:BuildProjectReferences=false /p:Configuration=Debug /verbosity:normal ProjectDir\Project.vcxproj
I ran into this problem recently (few days ago everything was working fine): Visual Studio 2012 started to refuse to build native WP8 projects.
Today, I created new solution from template 'Windows Phone Direct3D App (Native Only)' to check if my newly created DLLs will be properly supported on WP. I tried to compile this project, first without any changes or additional references - pure code generated by VS. However, it failed with given error.
I know very well what does it mean and what could be the possible reason, but I can't understand, hovewer, where does it come from in this case.
Weird thing: this only happens in 'Win32' configuration, ARM compiles fine:
1>------ Build started: Project: PhoneDirect3DApp, Configuration: Debug ARM ------
.......
Build Summary
-------------
00:11.742 - Success - Debug ARM - PhoneDirect3DApp\PhoneDirect3DApp.vcxproj
but Win32 does not:
1>------ Build started: Project: PhoneDirect3DApp, Configuration: Debug Win32 ------
.......
1>LINK : fatal error LNK1104: cannot open file 'kernel32.lib'
Build Summary
-------------
00:09.725 - Failed - Debug Win32 - PhoneDirect3DApp\PhoneDirect3DApp.vcxproj
My standard (native C++/Win32) projects also work as expected (in both Win32 and x64 platform targets).
Project configuration: (in both platforms)
Linker::Input:
d3d11.lib;%(AdditionalDependencies)
Linker::Ignore:
ole32.lib;%(IgnoreSpecificDefaultLibraries)
VC++ Directories:
Microsoft.ARM.Cpp.User:
$(WP80ToolSetPath)lib\arm;$(WindowsSDK_LibraryPath_ARM);
Microsoft.Win32.Cpp.User:
$(VCInstallDir)lib;$(VCInstallDir)atlmfc\lib;$(WP80ToolSetPath)lib\x86;$(WindowsSDK_LibraryPath_x86)
Any ideas what else could be wrong or configured incorrectly? I'm running out of ideas, I have never seen something like this before.
By the way, I have noticed one more change: when I was trying to compile WP8 projects in ARM configurtion before, there was always an error, saying "building ARM application on desktop is not supported" (or something like that). Now ARM compiles with no problem. Is it normal?
Finally, I have found the reason of my problems: as I suspected, internal Visual Studio configuration has been broken.
I did all standard steps, that can be performed in case of LNK1104, however:
- kernel32.lib was in valid location
- all include and library directories was correct
- standard *.props files were attached to each project
However, the cause was lying elsewhere.
All paths are defined using standard macros. One of them is $(WindowsSDK80Path), which is used to build include/library paths. On my system, this macro was defined as
C:\Program Files (x86)\Windows Phone Kits\8.0
instead of
C:\Program Files (x86)\Windows Kits\8.0
And that's it. I do not know, when or how, this problem arosed. Visual Studio repair via orginal installer was sufficient method to fix everything. All projects compile now without any problems.
What I'm having is that this error is displayed when I wanted to copy a exe debug project that I have created (which works witout any problems) to another machine (the error message is displayed).
According to the question posted previously, the best solution to get rid of the error message is to make a release and not a debug in the Configuration Manager.
Doing that, and when rebuilding the project with the RELEASE one, I'm having new errors in my project which were not included when doing the DEBUG.
For instance, one of them is :
Error 2 error C1083: Cannot open include file: 'opencv\highgui.h': No such file or directory c:\...\projects\...\ex\opencv.h 4
23 IntelliSense: identifier "IplImage" is undefined c:\...\ex.cpp 80
Any feedbacks?
You've probably added include paths for OpenCV to your project file. Unfortunately, Visual Studio by default makes such changes ONLY to the active configuration, which in your case was debug.
This rarely makes sense. Adding a logging library would be such a rare case, but you probably needs OpenCV in both debug and release builds.
MSVCP100.dll is part of the Microsoft Visual Studio 10 runtime. MSVCP100d.dll is the debug build of the same dll - useful for running your program in debug mode.
http://www.microsoft.com/en-us/download/details.aspx?id=5555
Basically it is a relatively new package and is not guaranteed to be on all systems, especially Windows XP, so you can distribute the required DLL files or the entire runtime with your program. EDIT: Keep in mind that debug builds are not meant to be distributed, so your program should not contain debug dll-s either such as MSVCP100d.dll.
Try downloading it, and then see what happens.
Also check out this question.
MSVCP100D.dll and MSVCP100.dll is part of the Microsoft Visual Studio 10 runtime, so if someone compile her/his programs with this package, then uninstall the package and install another one for example Microsoft Visual Studio 12 (2013).
When trying to run her/his programs , then her/his will get the message that 'so and so... try to reinstalling the program to fix this problem'. this means you have to reinstall Microsoft Visual Studio 10.
the other way is to recompile your programs under the new package!
When I try to debug my C++ application I get the error
The program can't start because MSVCP100D.dll is missing from your
computer. Try reinstalling the program to fix this problem.
I found someone with a similar problem here: Remote debugging C++ on the Windows Server 2008 platform with VS2010; MSVCP100D.dll missing however the solution given there doesn't seem to show up when I go to the solution properties.
Would reinstalling Visual Studio fix this problem?
Usually you don't want MSVCP100D.dll on your system. It's for debugging purposes only. If you get this error for your release build you must make sure that you didn't accidently add a 'Debug'-tagged Project Output to your setup project.
If you really need to debug your software on a remote machine, I suggest you do the following:
Create a new Setup project called 'CRTDebug100Setup' and add the following Merge Modules (found under C:\Program Files\Common Files\Merge Modules):
Microsoft_VC90_DebugCRT_x86.msm
policy_9_0_Microsoft_VC90_DebugCRT_x86.msm
Build, and deploy on your computer to be debugged!
Reinstalling Visual Studio fixed the problem.
This can also occur if Generate Debug info is not set to No
Configuration Properties -> Linker -> Debugging -> Generate Debug info
Followup on l33t's answer above (tried to revise it but it did not seem to appear).
Added later by gpicher 10 Jan 2012: I believe those .msm packages would be for a 9.x version of the DLL in question, not a 10.x version. I resolved a similar problem I had by making a setup project with Visual Studio 2010 installed on a 64 bit Windows installation, using the merge module Microsoft_VC100_DebugCRT_x86.msm in the folder C:\Program Files (x86)\Common Files\Merge Modules. There's a similar x64 version of the .msm if the application showing the error dialog is a 64 bit application. In this case a third party was providing me a debug build of their application in order to develop and test new plugin code against, so I couldn't change build settings, and wanted the debug functionality.
Find the Visual Studio 2010 install iso file.
Extract cab44.cab file from the ISO.
Then extract file "F_REDIST_DLL_APPLOCAL_msvcp100d_x86" from the .cab file using 7z.
Rename the file to msvcp100d.dll.
For x64 version. The cab file name is cab26.cab and the file name is F_REDIST_DLL_APPLOCAL_msvcp100d_x64.
For similar issue such missing msvcr*d.dll for another visual studio version. Here is the way I used to find the answer:
Find the Visual Studio ISO.
Extract all the .cab file.
7z.exe t *.cab > filelist.txt
gvim filelist.txt
searching for the interested file name. Hope this helps.