我正在尝试构建一个包含多个C ++ .vcproj的VS .sln。解决方案文件是使用CMake生成的，我已经将这部分工作在Jenkins中（使用CMake builder插件）。要构建解决方案文件，我使用的是msbuild。我可以使用Visual Studio和命令行使用以下命令构建解决方案：
C:\Jenkins\workspace\SonioTest>"C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe" /t:Rebuild bin/SonIO.sln
这构建成功（在Jenkins所在的同一台机器上）。
但是，我正在尝试在Jenkins中自动化这部分构建，并且构建最终失败并出现几个C1083错误（"Cannot open source file: '..\path\to\file.ext': No such file or directory）。我尝试使用Jenkins msbuild插件并使用在终端中工作的完全相同的命令作为“执行Windows批处理命令”构建步骤，结果相同。
使用Windows批处理命令构建步骤时，我可以在日志中看到正在执行的命令：
C:\Jenkins\workspace\SonioTest>"C:\Windows\Microsoft.NET\Framework\v4.0.30319 msbuild.exe" /t:Rebuild bin/SonIO.sln
...与从命令行工作的那个完全相同，包括工作目录。
我正在运行Jenkins作为服务，我将服务登录作为我的帐户（具有管理员权限）。任何人都知道Jenkins将从哪个目录执行批处理命令？
任何想法为什么我看到Jenkins和命令行之间的这种行为差异？
答案 0 :(得分：3)
这是解决方案的一种解决方法，但我最终使用的是devenv而不是msbuild，它运行正常。
我知道这很强烈暗示它是一个环境问题，但是因为在构建服务器上安装VS并不是一个问题，所以我决定节省在msbuild兔子洞中花费的时间。
答案 1 :(得分：1)
在不了解VS构建的情况下，它看起来很像环境设置。
我的第一个建议是确保在Jenkins中将目录更改为运行良好命令的同一目录，然后再尝试。
此外，可能希望首先尝试将Jenkins作为独立应用程序运行。
作为一项服务，也许允许服务“与桌面交互”。
答案 2 :(得分：1)
帐户使用的环境是Jenkins从属代理与您在提示中执行相同命令行时使用的环境不同。比较两个环境，记下差异，然后将它们添加到Jenkins作业中。
为了在跑步时获得奴隶的环境，让它做一个＆＃34;设置＆＃34;从Windows命令提示符
答案 3 :(得分：0)
我可能参加聚会的时间很晚，但是我仍然在Server 2016的新Jenkins设置上遇到此问题。
我的解决方案是直接在VS2017安装C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin中使用MSBUILD。没有更多的错误。