Msbuild通过VS和命令行运行，但通过Jenkins失败

Question

I am trying to build a VS .sln that has multiple C++ .vcproj's in it. The solution file is generated using CMake and I've got this part working in Jenkins (with the CMake builder plugin). To build the solution file, I am using msbuild. I am able to build the solution using both Visual Studio and from the command line with the following command:

C:\Jenkins\workspace\SonioTest>"C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe" /t:Rebuild bin/SonIO.sln

This builds successfully (on the same machine that Jenkins resides).

However, I am trying to automate this portion of the build in Jenkins and the build ends up failing with a couple of C1083 errors ( "Cannot open source file: '..\\path\\to\\file.ext': No such file or directory ). I have tried using both the Jenkins msbuild plugin and using the exact same command that works in the terminal as a "Execute Windows batch command" build step, with the same result.

When using the Windows batch command build step, I can see in the log that the command being executed:

C:\Jenkins\workspace\SonioTest>"C:\Windows\Microsoft.NET\Framework\v4.0.30319 msbuild.exe" /t:Rebuild bin/SonIO.sln

... is exactly the same as the one that works from the command line, including the working directory.

I am running Jenkins as a service and I have the service logon as my account (with administrator privileges). Anyone know what directory Jenkins will execute batch commands out of?

Any ideas why I'm seeing this difference of behavior between Jenkins and the command line?

Answer 1

This is as much a workaround as a solution, but I ended up using devenv instead of msbuild and it works fine.

I know that this hints strongly as it being an environmental issue, but since it's not a problem to have VS installed on the build server, I decided to save the time that would be spent in the msbuild rabbit hole.

Answer 2

Without knowing much about VS build, it looks mostly like an environment setup.

My first advice would be to make sure, in Jenkins, you change directory to the same directory you ran the good command from and try it then.

Also, might want to try running Jenkins as a standalone app first.

And as a service, maybe allow service to "interact with desktop".

Answer 3

The environment being used by the account that the Jenkins slave agent is not the same environment as you use when doing the same command line from a prompt. Compare the two environments, note the difference, then add them to the Jenkins job.

To get the environment of the slave while running, have it do a "set" from a Windows Command Prompt

Answer 4

I may be late to the party, but I still ran into this problem on a new Jenkins setup on Server 2016.

My solution was to use the MSBUILD straight from the VS2017 installation C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\BuildTools\\MSBuild\\15.0\\Bin . No more errors.