title: <msbuild/> task fails while <devenv/> succeeds for MFC application in CruiseControl.NET?
body: <p><strong>The Overview</strong></p>
  
  <p>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 (<code>&lt;devenv/&gt;</code>) works, but a simple MSBuild wrapper script (see below) run via the CCNet <code>&lt;msbuild/&gt;</code> task fails with errors like:</p>
  
  <ul>
  <li>error RC1015: cannot open include file 'winres.h'..</li>
  <li>error C1083: Cannot open include file: 'afxwin.h': No such file or directory</li>
  <li>error C1083: Cannot open include file: 'afx.h': No such file or directory</li>
  </ul>
  
  <p><strong>The Question</strong></p>
  
  <p>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?)</p>
  
  <p><strong>Background Details</strong></p>
  
  <ul>
  <li>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. </li>
  <li>Now I am working on compiling the application on the CI server environment</li>
  <li>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.</li>
  <li>VS2010 is correctly installed on the CI server, and the devenv task works as expected</li>
  <li>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. </li>
  <li>This wrapper script is run via CCNet's MSBuild task and fails with the above mentioned errors</li>
  </ul>
  
  <p><strong>The Simple MSBuild Wrapper</strong></p>
  
  <pre><code>&lt;?xml version="1.0" encoding="utf-8"?&gt;
  &lt;Project ToolsVersion="4.0" DefaultTargets="Build"
     xmlns="http://schemas.microsoft.com/developer/msbuild/2003"&gt;
    &lt;Target Name="Build"&gt;
      &lt;!-- Doing some versioning stuff here--&gt;
      &lt;MSBuild Projects="target.sln" 
        Properties="Configuration=ReleaseUnicode;Platform=Any CPU;..." /&gt;
    &lt;/Target&gt;
  &lt;/Project&gt;
  </code></pre>
  
  <p><strong>My Assumptions</strong></p>
  
  <ul>
  <li>This seems to be a missing/wrong configuration of include paths to standard header resources of the MFC persuasion</li>
  <li>I should be able to coerce the MSBuild environment to consider the relevant resource files from my VS2010 install and have this approach work.</li>
  <li>Given the vs2010 msbuild support for visual c++ projects (.vcxproj), shouldn't msbuilding a solution be pretty close to compiling via visual studio?</li>
  </ul>
  
  <p>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. </p>
  
  <p><strong>Update 1</strong></p>
  
  <p>This appears to only ever happen in two cases: resource compilation (rc.exe), and precompiled header (stdafx.h) compilation, and only for certain projects? I was thinking it was across the board, but indeed it appears only to be in these cases. I guess I will keep digging and hope someone has some insight they would be willing to share...</p>
  
  <p><strong>Solution</strong></p>
  
  <p>I made two adjustments to get this working. The first was to pull a 3rd-party project from my solution and build it independently (it had the lion's share of errors). By checking in it's binary to source control (like many of the other 3rd-party libraries) I was linking to it without issue. As many would point out, however, this was just an avoidance of the problem.</p>
  
  <p>The second part of the solution was incidentally found, but explicitly implied by the checklist of W. Craig Trader's suggestion. That is, I pulled source code to my working directory on the server manually and built the solution manually in visual studio. Whatever path/environment/configuration state issue that existed was ironed out by actually firing up visual studio for that ccnet service user. It certainly makes sense in retrospect. </p>