Icon

You are viewing the documentation of TeamCity 10.x and 2017.x, which is not the most recently released version of TeamCity.
View this page in TeamCity 2018.1 documentation or refer to the listing to choose the documentation corresponding to your TeamCity version.

 
Skip to end of metadata
Go to start of metadata

If you experience any problems running Visual C++ build on a build agent, you can try to workaround these issues with the following steps, sequentially:

Icon

Any of these steps may solve your issue. Please feel free to leave feedback of you experience.

  • Make sure you do not use mapped network drives.
  • Make sure build user have enough right to access necessary network paths
  • Log on to the build agent machine under the same user as for build and try running the following command:
  • Build Agent service runs under the user with local administrative privileges
  • Make sure Microsoft Visual Studio is installed on the build agent
  • You have to start Visual Studio 2005 or Visual Studio 2008 under build user once http://www.jetbrains.net/devnet/message/5233781#5233781
  • If Error spawning cmd.exe appears, you should put the following lines exactly into the list in Tools -> Options -> Projects and Solutions -> VC++ Directories:
    http://www.jetbrains.net/devnet/message/5217957#5217957
  • You need to add all environment variables from ...\Microsoft Visual Studio 9.0\VC\vcvarsall.bat to environment or to buildAgent.properties file
  • Try using devenv.exe with Command Line Runner instead of Visual Studio(sln) build runner
  • Ensure all paths to sources do not contain spaces
  • Set VCBuildUserEnvironment=true in runner properties
  • Specify 'VCBuildAdditionalOptions' property with value '/useenv' in the build configuration settings to instruct msbuild to add '/useenv' commandline argument for spawned vcbuild processes.



See also:

  • No labels

1 Comment

  1. I just ran into the problem with VCBuild.exe failing to spawn cmd.exe during a mixed C#/C++ solution build. I am using my own user account to run the build agent as a service, and the account is an admin on the box. Exposing the environment path via an echo in one of the earlier project shows that it contains the "system" portion of the path but not the "user" portion (as seen in Windows System Properties -> Advanced -> Environment Variables), and it is the user path that contains C:\WINNT\System32, which is where cmd.exe resides. I have worked around this by setting the full path in the buildAgent.properties as suggested above, but this looks like a bug in the build agent to me.