Msbuild funktioniert über VS und Kommandozeile, scheitert aber über Jenkins

Question

Ich versuche eine VS .sln zu erstellen, die mehrere C++ .vcprojs enthält. Die Lösungsdatei wird mit CMake generiert und ich habe diesen Teil in Jenkins (mit dem CMake Builder Plugin). Um die Lösungsdatei zu erstellen, verwende ich msbuild. Ich bin in der Lage, die Lösung mit dem folgenden Befehl Visual Studio und von der Kommandozeile zu bauen:

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

erfolgreich Dies baut (auf der gleichen Maschine, die Jenkins befindet).

Allerdings versuche ich diesen Teil des Build in Jenkins zu automatisieren und der Build endet mit ein paar C1083 Fehler ("Cannot open source file: '..\path\to\file.ext': No such file or directory). Ich habe versucht, sowohl das Jenkins-Msbuild-Plugin und den gleichen Befehl zu verwenden, der im Terminal als Build-Schritt "Windows-Batch-Befehl ausführen" mit dem gleichen Ergebnis funktioniert.

Wenn Sie den Befehl Build-Schritt Windows-Batch verwendet wird, kann ich im Protokoll sehen, dass der Befehl ausgeführt wird:

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

... ist genau das gleiche wie die, die von der Kommandozeile arbeiten , einschließlich das Arbeitsverzeichnis.

Ich verwende Jenkins als Dienst und ich habe die Service-Anmeldung als mein Konto (mit Administratorrechten). Wer weiß, in welchem ​​Verzeichnis Jenkins Stapelbefehle ausführen wird?

Irgendwelche Ideen, warum ich diesen Unterschied des Verhaltens zwischen Jenkins und der Befehlszeile sehe?

Answer 1

Ohne viel über VS-Build zu wissen, sieht es meistens wie eine Umgebung aus.

Mein erster Ratschlag wäre sicher zu stellen, dass Sie in Jenkins das Verzeichnis in dasselbe Verzeichnis wechseln, in dem Sie den guten Befehl ausgeführt haben, und versuchen Sie es dann.

Vielleicht möchten Sie auch Jenkins als eigenständige Anwendung zuerst ausführen.

Und als Service, vielleicht Service erlauben "Interaktion mit Desktop".

Ich hoffe, dass dies eine gute Führung ist ...

Answer 2

Dies ist so viel eine Abhilfe in Form einer Lösung, aber ich endete mit devenv statt msbuild und es funktioniert gut.

Ich weiß, dass dies stark darauf hindeutet, dass es ein Umweltproblem ist, aber da es kein Problem ist, VS auf dem Build-Server installiert zu haben, habe ich beschlossen, die Zeit zu sparen, die in der Msbuild Kaninchen Loch verbracht würde.

Answer 3

Die Umgebung, die von dem Konto verwendet wird, dass der Jenkins-Slave-Agent nicht dieselbe Umgebung ist, in der Sie dieselbe Befehlszeile von einer Eingabeaufforderung aus ausführen. Vergleichen Sie die beiden Umgebungen, notieren Sie den Unterschied und fügen Sie sie dann dem Jenkins-Job hinzu.

Um die Umgebung des Slave bekommen beim Laufen, haben es von einem Windows-Befehl ein „Satz“ Keine Aufforderung