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.