MsbuildはVSとコマンドライン経由で動作しますが、Jenkins経由では失敗します。

Question

複数の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でビルドのこの部分を自動化しようとしており、ビルドにはいくつかのエラーC1083（"Cannot open source file: '..\path\to\file.ext': No such file or directory）が失敗してしまいます。私はJenkins msbuildプラグインと同じ結果を持つ "Execute Windows batch command"ビルドステップとしてターミナルで動作する全く同じコマンドを使用してみました。

Windowsバッチコマンドのビルドステップを使用している場合、私は、コマンドが実行されていることをログで確認できます。

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

...は、コマンドラインから作品1とまったく同じです、、などがあります。

私はJenkinsをサービスとして実行しており、サービスログオンは自分のアカウントとして（管理者権限で）持っています。どの人がJenkinsがバッチコマンドを実行するディレクトリを知っていますか？

Jenkinsとコマンドラインの間にこのような動作の違いがある理由は何ですか？

Answer 1

VSビルドについてよく知らなくても、ほとんど環境設定のように見えます。

私の最初のアドバイスは、Jenkinsでは、goodコマンドを実行したディレクトリと同じディレクトリにディレクトリを変更してから試してみることです。

また、Jenkinsをスタンドアロンアプリとして実行してみてください。

サービスとして、サービスが「デスクトップとやりとりする」ことを可能にするかもしれません。

私は

Answer 2

...これは良いリードであると思いますこれは、多くの解決策として、回避策ですが、私はdevenv代わりのmsbuildを使用して終了し、それが正常に動作します。

これは環境問題として強く示唆されていますが、VSをビルドサーバーにインストールするのは問題ではないため、私はmsbuildウサギの穴に費やす時間を節約することにしました。

Answer 3

Jenkinsスレーブエージェントが、プロンプトから同じコマンドラインを実行するときに使用するのと同じ環境ではないアカウントによって使用されている環境。 2つの環境を比較し、違いをメモしてから、それらをJenkinsジョブに追加します。

実行中にスレーブの環境を得るために、それはWindowsのコマンドから「設定」ん持って