MSBuild "Wrapper" fails while VS2010 "Pure" compile succeeds for MFC application in CruiseControl.NE
- by ee
The Overview
I am working on a Continuous Integration build of a MFC appliction via CruiseControl.net and VS2010. When building my .sln, a "Visual Studio" CCNet task (devenv) works, but a wrapper MSBuild script run via the CCNet MSBuild task fails with errors like:
error RC1015: cannot open include file 'winres.h'..
error C1083: Cannot open include file: 'afxwin.h': No such file or directory
error C1083: Cannot open include file: 'afx.h': No such file or directory
The Question
How can I adjust the build environment of my msbuild wrapper so that the application builds correctly? (Pretty clearly the MFC paths aren't right for the msbuild environment, but how do i fix it for MSBuild+VS2010+MFC+CCNet?)
Background Details
We have successfully upgraded an MFC application (.exe with some MFC extension .dlls) to Visual Studio 2010 and can compile the application without issue on developer machines.
Now I am working on compiling the application on the CI server environment
I did a full installation of VS2010 (Professional) on the build server. In this way, I knew everything I needed would be on the machine (one way or another) and that this would be consistent with developer machines.
VS2010 is correctly installed on the CI server, and the devenv task works as expected
I now have a wrapper MSBuild script that does some extended version processing and then builds the .sln for the application via an MSBuild task.
This wrapper script is run via CCNet's MSBuild task and fails with the above mentioned errors
My Assumptions
This seems to be a missing/wrong configuration of include paths to standard header resources of the MFC persuasion
I should be able to coerce the MSBuild environment to consider the relevant resource files from my VS2010 install and have this approach work.
But how do I do that? Am I setting Environment variables? Registry settings? I can see how one can inject additional directories in some cases, but this seems to need a more systemic configuration at the compiler defaults level.