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
