0

We just recently started getting warnings on our build system which are eventually causing the build to fail. The build works fine if I build in the VS2005 IDE.

The error seems to boil down to the following error:

Task "ResolveVCProjectOutput" skipped, due to false condition; ( ('$(Configuration)' == 'Debug') and ('$(Platform)' == 'Win32') ) was evaluated as ( ('Release' == 'Debug') and ('Win32' == 'Win32') ).

I am trying to build in release mode, but it seems that the ResolveVCProjectOutput can only handle debug mode.

I am building for Win32 on a 64 bit machine in VS2005 using msbuild.

In case it's relevant, here is a bit more of the build output:

Task "Delete"
Deleting file "D:\Farm\MSVC80\Builds\RetargetingPluginsDeploymentWindows\RetargetingPlugins\Install\XSIRetargetInstallerWindows\XSIRetargetInstallerWindows.tmp_Release_Win32.vcproj".
Command:
del "D:\Farm\MSVC80\Builds\RetargetingPluginsDeploymentWindows\RetargetingPlugins\Install\XSIRetargetInstallerWindows\XSIRetargetInstallerWindows.tmp_Release_Win32.vcproj"
Done executing task "Delete".
Done building target "XSIRetargetInstallerWindows" in project "Slave.sln".
Target "MotionBuilderRetargetInstallerWindows" skipped. Previously built successfully.
Target "MayaRetargetInstallerWindows" skipped. Previously built successfully.
Target "MaxRetargetInstaller" skipped. Previously built successfully.
Target "RetargetingPluginsDeploymentWindows" in file "D:\Farm\MSVC80\Builds\RetargetingPluginsDeploymentWindows\Slave.sln":
Task "ResolveVCProjectOutput" skipped, due to false condition; ( ('$(Configuration)' == 'Debug') and ('$(Platform)' == 'Win32') ) was evaluated as ( ('Release' == 'Debug') and ('Win32' == 'Win32') ).
Task "CreateItem"
Done executing task "CreateItem".
Task "ResolveVCProjectOutput" skipped, due to false condition; ( ('$(Configuration)' == 'Debug') and ('$(Platform)' == 'Win32') ) was evaluated as ( ('Release' == 'Debug') and ('Win32' == 'Win32') ).
Task "CreateItem"
Done executing task "CreateItem".
Task "ResolveVCProjectOutput" skipped, due to false condition; ( ('$(Configuration)' == 'Debug') and ('$(Platform)' == 'Win32') ) was evaluated as ( ('Release' == 'Debug') and ('Win32' == 'Win32') ).
Task "CreateItem"
Done executing task "CreateItem".
Task "ResolveVCProjectOutput" skipped, due to false condition; ( ('$(Configuration)' == 'Debug') and ('$(Platform)' == 'Win32') ) was evaluated as ( ('Release' == 'Debug') and ('Win32' == 'Win32') ).
Task "CreateItem"
Done executing task "CreateItem".
Task "CreateTemporaryVCProject" skipped, due to false condition; ( ('$(Configuration)' == 'Debug') and ('$(Platform)' == 'Win32') ) was evaluated as ( ('Release' == 'Debug') and ('Win32' == 'Win32') ).
Task "VCBuild" skipped, due to false condition; ( ('$(Configuration)' == 'Debug') and ('$(Platform)' == 'Win32') ) was evaluated as ( ('Release' == 'Debug') and ('Win32' == 'Win32') ).
Task "Delete" skipped, due to false condition; ( ('$(Configuration)' == 'Debug') and ('$(Platform)' == 'Win32') ) was evaluated as ( ('Release' == 'Debug') and ('Win32' == 'Win32') ).
Task "ResolveVCProjectOutput"
Resolving VC project reference "D:\Farm\MSVC80\Builds\RetargetingPluginsDeploymentWindows\RetargetingPlugins\Install\XSIRetargetInstallerWindows\XSIRetargetInstallerWindows.vcproj".
D:\Farm\MSVC80\Builds\RetargetingPluginsDeploymentWindows\Slave.sln : warning MSB3422: Failed to retrieve VC project information through the VC project engine object model. Unable to determine default tool for the specified file configuration.
D:\Farm\MSVC80\Builds\RetargetingPluginsDeploymentWindows\Slave.sln : warning MSB3425: Could not resolve VC project reference "D:\Farm\MSVC80\Builds\RetargetingPluginsDeploymentWindows\RetargetingPlugins\Install\XSIRetargetInstallerWindows\XSIRetargetInstallerWindows.vcproj".
Done executing task "ResolveVCProjectOutput".

Liron
  • 2,012
  • 19
  • 39
  • Have you considered using property sheets to define build outputs and project directories? Also you can build with visual studio via command line by calling devenv.exe which is what I ended up using in my automated build from a C# build program for my various C++ solutions and installs. – AJG85 Mar 16 '11 at 17:55
  • Mysterious, that target doesn't have a condition that checks the $(Configuration). Did somebody edit Microsoft.Common.targets on that machine? – Hans Passant Mar 16 '11 at 18:25

3 Answers3

0

I have run into a similar situation after I had made manual modifications to project and solution files during a subversion merge. Solution files can be really cryptic and one can easily make mistakes with manual edits. Anyway, after the merge the build system apparently didn't like some of the projects or GUIDs associated with them and failed.

What I did to solve the problem was to recreate the conflicting project from scratch in the IDE using the project wizard (Add New Project...). After that, the warnings went away.

Hendrik
  • 569
  • 3
  • 12
0

I also had this problem (MSB3422 and MSB3425) running VS2008 and the solution was to recreate the affected projects from scratch using the VS2008 IDE.

msan
  • 1
0

I had a mysteriously similar problem when building VC++ projects prior to VS 2010. What happens is that vcbuild.exe (which is eventually used when building .vcproj files even from msbuild) parses the project file and freezes the value of $(Configuration) on the first one that is found. The evaluation of any other strings containing $(Configuration) will always evaluate to the first one, which is typically "Debug". For references, if you are doing a clean Release build, the referenced items in the "Debug" folders won't exist. If you are doing a "dirty" build, they may exist and this will sometimes appear to work, but can cause out-of-date issues.

The resolution was pretty nasty, basically boiling down to a custom build task driven from a controlling MSBuild project that made a copy of the .vcproj files, then stripped out the configurations not being built, then built the temporary stripped down project instead of the original. It was either that or have to keep two separate project files in sync for each project, and we had hundreds of them.

As an experiment, rework some of the project files (and any that they reference, and so on) so that the "Release" configuration appears first and see if you get different behavior.

Brian Kretzler
  • 9,748
  • 1
  • 31
  • 28
  • Seems that we had an issue with setting the configuration names. I can't remember what we were doing wrong but it had something to with needing an extra space or having an extra space in Win32. – Liron Feb 23 '12 at 11:25