다음을 통해 공유

Building VC++ 2005 Projects With Team Build 2008

  • 아티클

MSBuild introduced a multi-targeting feature in VS 2008 that allows it to build managed code projects that target previous versions of the .NET Framework (and all associated tools - the Microsoft.Common.targets file, the MSBuild engine itself, etc.).  Unfortunately, there is no corresponding functionality for VC++ projects, since these are still not MSBuild compatible project files.  MSBuild can build solutions containing VC++ projects, but there will be issues when building solutions containing VC++ 2005 (version 8) projects with the VS 2008 MSBuild engine (.NET Framework version 3.5) and thus with Team Build 2008.

In particular, you will notice messages similar to the following in your build log:

vcbuild.exe : error VCBLD0010: Project '<project name>' requires upgrade. Use 'vcbuild /upgrade' or 'devenv /upgrade' to upgrade the project.

The project file that MSBuild generates to build solutions uses something like the following VCBuild task invocation to build VC++ projects:

 <VCBuild Projects="foo.vcproj" 
         ToolPath="$(VCBuildToolPath)" 
         Configuration="Configuration|Platform" 
         SolutionFile="foo.sln" 
         Override="$(VCBuildOverride)" 
         AdditionalLibPaths="$(VCBuildAdditionalLibPaths)" 
         UserEnvironment="$(VCBuildUserEnvironment)" 
         AdditionalOptions="$(VCBuildAdditionalOptions)" 
         Condition=" ('$(Configuration)' == 'Configuration') and ('$(Platform)' == 'Platform') " />

The trick is that this will always use the VCBuild task from the 3.5 .NET Framework directory, and this task will always invoke VCBuild 2008.  Note, however, the VCBuildToolPath property - this allows you to override the path to vcbuild.exe used by the task, and provides the workaround that allows building VC++ 2005 projects without upgrading them.

In particular, you can add something like the following text to your TfsBuild.rsp file if all the solutions in your Team Build build contain VC++ 2005 projects:

/p:vcbuildtoolpath="$(ProgramFiles)\Microsoft Visual Studio 8\vc\vcpackages"

If some of your solutions contain VC++ 2005 projects and some contain VC++ 2008 projects, you can specify the property on a solution-specific basis using the Properties metadata of the SolutionToBuild item group as follows:

 <ItemGroup>
  <SolutionToBuild Include="VCBuild_2005.sln">
    <Properties>vcbuildtoolpath=$(ProgramFiles)\Microsoft Visual Studio 8\vc\vcpackages</Properties>
  </SolutionToBuild>
  <SolutionToBuild Include="VCBuild_2008.sln">
    <Properties></Properties>
  </SolutionToBuild>
</ItemGroup>

Comments

  • Anonymous
    October 30, 2007
    PingBack from http://www.christian.luiscorreia.com/building-vc-2005-projects-with-team-build-2008/
  • Anonymous
    October 30, 2007
    Wonder why MSBuild 3.5 cannot VC++ projects. Using VCBuild is no fun.Take a look at CodeGear C++Builder 2007, the projects can  be built with MSBuild 2.0 smoothly.
  • Anonymous
    April 28, 2008
    I tried the RSP method using TeamBuild 2008 and it caused MSBuild to throw an error saying that you can only build one project at a time.   Does the property need to be escaped somehow?I switched the the TeamBuildType method of setting the property for the SolutionToBuild and it worked.Well, almost work.  LIB1/DLL1 built and now EXE1 that consumes LIB is throwing the error:LNK1181: cannot open input file 'C:TEAMBUILDSandbox-AgileGatlinBinariesWin32Releasegatlin.lib'
  • Anonymous
    April 28, 2008
    Whoops - probably the rsp file needs double quotes around the path, since it includes whitespace.  I'll update the post accordingly.Not sure about the second error - try posting it to our forums (at http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=481&SiteID=1) and posting a link to the thread here.
  • Anonymous
    April 28, 2008
    Thanks, I've posted.   I'm still trying to learn the VCPROJ world... I put a postbuild event in DLL1 and from VS2005 it runs. From VCBuild it doesn't run.   If I turn EXE1 off in the configuration manager, I get a good build....Well, amost good build. :-)   It doesn't actually copy anything up to the Binaries file for dropping in the archives.  I'm sure that's why my lib consumption is failing also as that's where it's trying to link it from.  The catch, is I just don't know why yet. ;-)