Msbuild funziona tramite VS e riga di comando, ma non riesce via Jenkins

Question

Sto provando a creare un file .sln VS con più file .vcproj in C++. Il file della soluzione viene generato utilizzando CMake e ho questo componente che funziona in Jenkins (con il plugin del builder CMake). Per costruire il file della soluzione, sto usando msbuild. Sono in grado di creare la soluzione utilizzando sia Visual Studio e dalla riga di comando con il seguente comando:

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

Questo costruisce con successo (sulla stessa macchina che Jenkins risiede).

Tuttavia, sto tentando di automatizzare questa parte della build in Jenkins e la build non riesce con un paio di errori C1083 ("Cannot open source file: '..\path\to\file.ext': No such file or directory). Ho provato ad usare sia il plug-in di msgen di Jenkins che lo stesso comando che funziona nel terminale come un passo di generazione "Esegui comando batch di Windows", con lo stesso risultato.

Quando si utilizza il comando batch passo accumulo di Windows, posso vedere nel log che il comando in esecuzione:

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

... è esattamente lo stesso di quello che funziona da linea di comando , incluso la directory di lavoro.

Sto eseguendo Jenkins come servizio e ho l'accesso al servizio come account (con privilegi di amministratore). Qualcuno sa da quale directory Jenkins eseguirà i comandi batch?

Qualche idea del perché sto osservando questa differenza di comportamento tra Jenkins e la riga di comando?

Answer 1

Senza sapere molto su VS build, sembra per lo più come un ambiente di installazione.

Il mio primo consiglio sarebbe di accertarmi, in Jenkins, di cambiare la directory nella stessa directory da cui è stato eseguito il buon comando e provarlo poi.

Inoltre, potrebbe voler provare a far funzionare Jenkins come app standalone.

E come servizio, forse consentire al servizio di "interagire con il desktop".

Spero che questo sia un buon vantaggio ...

Answer 2

Questo è tanto una soluzione come una soluzione, ma ho finito per usare devenv invece di msbuild e funziona benissimo.

So che questo suggerisce fortemente come un problema ambientale, ma poiché non è un problema avere VS installato sul server di build, ho deciso di salvare il tempo che sarebbe stato speso nel buco del coniglio di msbuild.

Answer 3

L'ambiente utilizzato dall'account che l'agente slave Jenkins non è lo stesso ambiente che si utilizza quando si esegue la stessa riga di comando da un prompt. Confronta i due ambienti, nota la differenza, quindi aggiungili al lavoro di Jenkins.

Per ottenere l'ambiente dello schiavo durante l'esecuzione, fare fare un "set" da un comando di Windows Prompt